Kako dodati prijavu u vašu aplikaciju: lozinke, magični linkovi, Google i uloge

Da biste dodali prijavu u aplikaciju, izaberite metod (email i lozinka, magični linkovi, tj. jednokratni link za prijavu poslan emailom, ili "Prijava preko Googlea") i implementirajte ga pomoću provjerene biblioteke za autentikaciju ili hostovanog dobavljača, a ne od nule. Zatim odlučite šta svaka vrsta korisnika smije da radi (uloge) i to provodite na serveru za svaku stranicu i svaki API zahtjev. Sesije treba da koriste sigurne kolačiće, da istječu i da se pravilno završavaju pri odjavi.

Ovaj vodič prolazi kroz svaki izbor i detalje koji razdvajaju radnu prijavu od sigurne. Za koncepte iza toga, pogledajte šta je autentikacija.

Prvo odlučite: da li vam uopšte treba prijava?

Prijava donosi trenje i odgovornost. Treba vam kada:

• Korisnici imaju privatne podatke (svoje rezervacije, dokumente, fakture)
• Korisnici mogu mijenjati stvari koje drugi vide
• Naplaćujete pristup
• Različiti ljudi trebaju različite dozvole (vlasnik naspram osoblja naspram kupca)

Ne treba vam za marketing stranicu, javni imenik ili obrazac koji vam samo šalje email. Lista čekanja ne treba naloge; dovoljno je polje za email.

Četiri uobičajena metoda prijave

Mnoge aplikacije kombinuju dva: prijava preko Googlea plus magični linkovi preko emaila popularan je par koji pokriva većinu ljudi bez čuvanja ijedne lozinke.

Email i lozinka

Ako nudite lozinke, ovo su neopozivi zahtjevi:

• Hashujte lozinke sporim algoritmom za hashiranje lozinki. OWASP-ove smjernice za čuvanje lozinki preporučuju Argon2id, a kao alternative scrypt, bcrypt ili PBKDF2. Nikada ne čuvajte lozinke u običnom tekstu ili s brzim opštim hashom.
• Resetovanje lozinke koristi nasumičan jednokratni link koji ističe, poslan na provjeren email.
• Ne otkrivajte koji emailovi imaju naloge. "Ako je taj email registrovan, poslali smo link za resetovanje" je bolje od "Nalog nije pronađen".
• Ograničite broj pokušaja prijave i resetovanja da usporite pogađanje lozinki.
• Dozvolite duge lozinke i menadžere lozinki; izbjegavajte pravila koja traže neobične kombinacije znakova.

Magični linkovi i jednokratni kodovi

Magični link je link za prijavu poslan korisniku emailom. Klik na njega prijavljuje korisnika. Jednokratni kod je ista ideja, ali se upisuje umjesto da se klikne.

• Linkovi i kodovi brzo istječu i rade samo jednom.
• Link treba da prijavi korisnika na uređaju na kojem je kliknuo, a token ne smije ostati u logovima ili alatima za analitiku.
• Potrebno vam je pouzdano slanje emaila; pogledajte kako slati emailove iz vaše aplikacije. Testirajte s Gmailom i Outlookom i provjerite spam fascikle.

Prijava preko Googlea (i drugih OAuth dobavljača)

"Prijava preko Googlea" koristi OAuth i OpenID Connect: Google potvrđuje ko je korisnik i vašoj aplikaciji kaže njegov email i ime. Podešavanje, od septembra 2026, radi se u sekciji Google Auth Platform u Google Cloud konzoli:

1. Napravite ili izaberite projekat i popunite stranicu Branding: šta korisnici vide na ekranu za saglasnost (naziv aplikacije, email za podršku, logotip).
2. Na stranici Clients napravite klijent tipa "Web application".
3. Dodajte authorized JavaScript origins i redirect URI: tačne adrese na kojima vaša aplikacija radi i na koje Google vraća korisnike nakon prijave.
4. Sačuvajte client ID i client secret u tajnama vaše aplikacije.

Stvari koje se često pokvare, prema Googlovoj OAuth dokumentaciji:

• redirect_uri_mismatch: adresa za preusmjeravanje mora se tačno poklopiti, uključujući http naspram https, velika i mala slova i završnu kosu crtu. Dodajte jednu za adresu pregleda i jednu za vaš živi domen.
• Obavezan HTTPS: redirect URI-ji moraju koristiti HTTPS, osim localhost tokom razvoja.
• Parametar state treba provjeriti pri povratku da bi se zaštitili od cross-site request forgery napada. Dobre biblioteke to rade umjesto vas.

Ako tražite samo osnovne informacije za prijavu (ime, email, profil), Google kaže da verifikacija aplikacije nije obavezna. Traženje pristupa Gmailu, Driveu ili Kalendaru korisnika je drugačije i zahtijeva verifikaciju.

Napravite sami ili koristite dobavljača?

Oba prva su razumna. Hostovani dobavljači rade više za vas, ali dodaju zavisnost i ponekad naplaćuju po aktivnom korisniku; provjerite aktuelne cijene na njihovim sajtovima. Biblioteke sve čuvaju u vašoj bazi, ali vam ostavljaju više da ispravno podesite. Šta god izaberete, zatražite od AI-ja da to koristi umjesto da sam piše logiku za lozinke ili sesije.

Uloge i dozvole

Prijava vam kaže ko je neko. Dozvole odlučuju šta smije da radi. Za početak držite jednostavno:

Pravila koja su važnija od naziva uloga:

• Provjeravajte na serveru, svaki put. Sakrivanje dugmeta na stranici ne sprječava nikoga da direktno pozove API.
• Ograničite po vlasniku. Član koji traži "rezervaciju 123" treba da je dobije samo ako je njegova.
• Korisnici ne mogu sami sebi dodijeliti ulogu. Ignorišite polja za ulogu koja stižu iz preglednika pri izmjeni profila.
• Podrazumijevano bez pristupa. Nove rute treba da zahtijevaju prijavu, osim ako sami odlučite drugačije.

Testirajte s dva naloga: prijavite se kao jedan, zabilježite ID zapisa, prijavite se kao drugi i pokušajte da ga otvorite. Naša sigurnosna lista za aplikacije pravljene AI-jem ima cijeli test.

Sigurnost sesije

Nakon prijave, aplikacija pamti korisnika pomoću sesije, obično kolačića. OWASP-ove smjernice za upravljanje sesijama preporučuju:

• Kolačići sesije postavljeni s Secure (samo HTTPS), HttpOnly (nečitljivi skriptama stranice) i SameSite
• Novi ID sesije izdat pri prijavi i ponovo kada se prava promijene
• Istek zbog neaktivnosti i apsolutno maksimalno trajanje, provjereno na serveru
• Odjava koja završava sesiju na serveru, a ne samo briše kolačić
• Sesije poništene kada korisnik promijeni lozinku

Čuvanje tokena za prijavu u localStorage-u preglednika je često u udžbenicima, ali izlaže ih svakoj skripti koja se izvršava na stranici; sigurni kolačići su obično bolji podrazumijevani izbor za web aplikacije.

Prompt koji pokriva osnove

Dodaj korisničke naloge u ovu aplikaciju. Korisnici se mogu registrovati i prijaviti s emailom i lozinkom ili s Googleom. Koristi [biblioteku ili dobavljača] umjesto prilagođenog koda za autentikaciju. Hashuj lozinke pomoću Argon2id ili bcrypt. Dodaj resetovanje lozinke emailom s jednokratnim linkom koji ističe za sat vremena. Čuvaj sesije u sigurnim HttpOnly kolačićima. Zaštiti /dashboard i svaku /api rutu tako da ih mogu koristiti samo prijavljeni korisnici i pobrini se da korisnici vide samo svoje projekte. Dodaj ulogu "admin" koja može vidjeti sve korisnike; samo administratori mogu doći do /admin, provjereno na serveru.

Zatim testirajte: registrujte se, odjavite se, prijavite se, resetujte lozinku, pokušajte privatni URL dok niste prijavljeni i pokušajte zapis drugog korisnika.

Česte greške u prijavi pravljenoj AI-jem

• Zaštita samo na stranici. Stranica preusmjerava odjavljene korisnike, ali API vraća podatke bilo kome.
• Tajne u pregledniku. OAuth client secret-i i administratorski ključevi dobavljača autentikacije pripadaju serveru.
• Pomiješani URL-ovi pregleda i živog sajta. Google-ov redirect URI ili link za resetovanje u emailu pokazuje na pregled, pa prijava pukne nakon objavljivanja.
• Nema verifikacije emaila. Neko se može registrovati kao anyone@company.com. Verifikujte email prije nego što dodijelite bilo šta vezano za tu adresu.
• Testiranje samo sretnog puta. Probajte pogrešne lozinke, istekle linkove i drugi nalog.

Dodavanje prijave u Mythexu

Na Mythexu, prijava za korisnike vaše aplikacije je nešto što dodajete u svoju aplikaciju; odvojena je od vašeg Mythex naloga. Mythex ne nudi ugrađeni proizvod za autentikaciju, pa donosite biblioteku ili dobavljača i njihove ključeve:

1. Izaberite pristup, na primjer email i lozinka sačuvani u vašoj bazi ili SDK hostovanog dobavljača.
2. Ako sami čuvate korisnike, aplikacija treba bazu podataka; zatražite je u chatu ili upišite /database.
3. Stavite ključeve dobavljača u tajne projekta (/secrets ili postavke projekta).
4. Koristite prompt kao gore, zatim testirajte u pregledu. Za prijavu preko Googlea, dodajte redirect URI-je i za adresu pregleda i za objavljenu adresu.

Pogledajte Add login to your app u dokumentaciji. Ako pravite plaćeni proizvod, kako napraviti SaaS MVP pokriva naloge i naplatu zajedno.

Pitanja