Kako dodati prijavu vašoj aplikaciji: lozinke, magične veze, Google i uloge
Da biste dodali prijavu aplikaciji, izaberite metod — email i lozinku, magične veze (jednokratnu vezu za prijavu poslatu emailom) ili "Prijava preko Googlea" — i implementirajte ga pomoću proverene biblioteke za autentikaciju ili hostovanog provajdera, a ne od nule. Zatim odredite šta svaka vrsta korisnika sme da radi (uloge), i to proveravajte na serveru za svaku stranicu i API zahtev. Sesije treba da koriste bezbedne kolačiće, da ističu i da se ispravno završavaju pri odjavi.
Ovaj vodič prolazi kroz svaki izbor i detalje koji razdvajaju radnu prijavu od bezbedne. 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, račune)
- Korisnici mogu da menjaju stvari koje će drugi videti
- Naplaćujete pristup
- Različiti ljudi treba da imaju različite dozvole (vlasnik naspram osoblja naspram kupca)
Možda vam ne treba za marketing sajt, javni direktorijum ili formular koji vam samo šalje email. Lista čekanja ne traži naloge; polje za email je dovoljno.
Četiri uobičajena metoda prijave
| Metod | Kako radi | Prednosti | Mane |
|---|---|---|---|
| Email i lozinka | Korisnik pravi lozinku; vi čuvate njen heš | Poznato, radi bez emaila | Resetovanje lozinki, ponovna upotreba, curenja; morate bezbedno čuvati lozinke |
| Magična veza | Korisnik unese email, klikne vezu koju mu pošaljete | Nema lozinki za čuvanje ili zaboravljanje | Zavisi od isporuke emaila; prijava je sporija |
| Jednokratni kod | Korisnik unese email, otkuca kod od 6 cifara | Radi kada se veze otvore u pogrešnom pregledaču | Ista zavisnost od emaila |
| Društvena / OAuth (Google, Apple, GitHub, Microsoft) | Drugi provajder potvrđuje ko je korisnik | Najbrže za korisnike; nema lozinke za vas da čuvate | Korisnici moraju imati taj nalog; podešavanje kod provajdera |
Mnoge aplikacije kombinuju dva: prijava preko Googlea plus magične veze putem emaila je popularan par koji pokriva većinu ljudi bez čuvanja ijedne lozinke.
Email i lozinka
Ako nudite lozinke, ovo nije za pregovaranje:
- Heširajte lozinke sporim algoritmom za heširanje lozinki. OWASP-ove smernice za čuvanje lozinki preporučuju Argon2id, a scrypt, bcrypt ili PBKDF2 kao alternative. Nikad ne čuvajte lozinke kao običan tekst ili sa brzim opštim heširanjem.
- Resetovanje lozinke koristi nasumičnu vezu za jednokratnu upotrebu koja ističe, poslatu na proveren email.
- Ne otkrivajte koji emailovi imaju nalog. "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; izbegavajte pravila koja traže čudnu kombinaciju znakova.
Magične veze i jednokratni kodovi
Magična veza je link za prijavu poslat korisniku emailom. Klik na njega prijavljuje korisnika. Jednokratni kod je ista ideja, ali se unosi umesto što se klikće.
- Veze i kodovi brzo ističu i rade samo jednom.
- Veza treba da prijavi korisnika na uređaju na kome je kliknuta, a token ne sme ostati u logovima ili alatima za analitiku.
- Potrebno vam je pouzdano slanje emaila — pogledajte kako slati emailove iz aplikacije. Testirajte sa Gmailom i Outlookom i proverite spam foldere.
Prijava preko Googlea (i drugih OAuth provajdera)
"Prijava preko Googlea" koristi OAuth i OpenID Connect: Google potvrđuje ko je korisnik i govori vašoj aplikaciji njegov email i ime. Podešavanje, od septembra 2026, odvija se u sekciji Google Auth Platform u Google Cloud konzoli:
- Napravite ili izaberite projekat i popunite stranicu Branding — šta korisnici vide na ekranu saglasnosti (naziv aplikacije, email za podršku, logo).
- Na stranici Clients napravite klijent tipa "Web application".
- Dodajte authorized JavaScript origins i redirect URI-je — tačne adrese na kojima vaša aplikacija radi i na koje Google vraća korisnike nakon prijave.
- Sačuvajte client ID i client secret u tajnama aplikacije.
Stvari koje često idu loše, prema Googleovoj OAuth dokumentaciji:
redirect_uri_mismatch: adresa za preusmeravanje mora se tačno poklapati, uključujućihttpnaspramhttps, velika i mala slova i završnu kosu crtu. Dodajte jednu za adresu pregleda i jednu za živi domen.- Potreban HTTPS: URI-ji za preusmeravanje moraju koristiti HTTPS, osim
localhosttokom razvoja. - Parametar
statetreba proveriti pri povratku radi zaštite od cross-site request forgery napada. Dobre biblioteke to rade za vas.
Ako tražite samo osnovne podatke za prijavu (ime, email, profil), Google kaže da verifikacija aplikacije nije obavezna. Traženje pristupa korisnikovom Gmailu, Drajvu ili Kalendaru je drugačije i zahteva verifikaciju.
Napraviti sami ili koristiti provajdera?
| Pristup | Primeri | Kada odgovara |
|---|---|---|
| Hostovani provajder autentikacije | Usluge koje hostuju prijavu, upravljanje korisnicima i sesije umesto vas | Želite da prijava radi brzo, uz manje bezbednosne odgovornosti |
| Biblioteka za autentikaciju u aplikaciji | Biblioteke otvorenog koda za vaš framework | Želite korisnike u sopstvenoj bazi i bez naknade po korisniku |
| Napraviti sami | — | Skoro nikad. Previše suptilnih detalja |
Oba prva pristupa su razumna. Hostovani provajderi rade više za vas, ali dodaju zavisnost i ponekad naplaćuju po aktivnom korisniku; proverite aktuelne cene na njihovim sajtovima. Biblioteke čuvaju sve u vašoj bazi, ali vam ostavljaju više posla da sve ispravno podesite. Šta god izaberete, zamolite AI da koristi to rešenje umesto da ručno piše logiku za lozinke ili sesije.
Uloge i dozvole
Prijava vam kaže ko je neko. Dozvole određuju šta smeju da rade. Za početak držite jednostavno:
| Uloga | Tipične dozvole |
|---|---|
| Posetilac | Vidi javne stranice |
| Član / kupac | Vidi i menja samo svoje zapise |
| Osoblje | Vidi sve zapise svog tima ili preduzeća; ne može da menja podešavanja ili naplatu |
| Vlasnik / administrator | Sve, uključujući korisnike i naplatu |
Pravila koja su važnija od naziva uloga:
- Proveravajte na serveru, svaki put. Sakrivanje dugmeta na stranici ne sprečava nikoga da direktno pozove API.
- Vezujte za vlasnika. Član koji traži "rezervaciju 123" treba da je dobije samo ako je njegova.
- Korisnici ne mogu sami sebi da dodele ulogu. Ignorišite polja za ulogu poslata iz pregledača pri izmeni profila.
- Podrazumevano bez pristupa. Nove rute treba da zahtevaju prijavu, osim ako odlučite drugačije.
Testirajte sa dva naloga: prijavite se kao jedan, zabeležite ID zapisa, pa se prijavite kao drugi i pokušajte da ga otvorite. Naša bezbednosna lista za aplikacije pravljene uz AI sadrži kompletan test.
Bezbednost sesije
Nakon prijave, aplikacija pamti korisnika kroz sesiju — obično kolačić. OWASP-ove smernice za upravljanje sesijama preporučuju:
- Kolačići sesije postavljeni sa
Secure(samo HTTPS),HttpOnly(nečitljivi za skripte stranice) iSameSite - Novi ID sesije pri prijavi, i ponovo kada se menjaju privilegije
- Vremensko ograničenje neaktivnosti i maksimalno trajanje sesije, sprovedeno na serveru
- Odjava koja završava sesiju na serveru, a ne samo briše kolačić
- Sesije poništene kada korisnik promeni lozinku
Čuvanje tokena za prijavu u local storage-u browsera je često u tutorijalima, ali izlaže ih svakoj skripti koja se izvršava na stranici; bezbedni kolačići su obično bolji podrazumevani izbor za veb aplikacije.
Prompt koji pokriva osnove
Dodaj korisničke naloge ovoj aplikaciji. Korisnici mogu da se registruju i prijave sa emailom i lozinkom, ili preko Googlea. Koristi [biblioteka ili provajder] umesto prilagođenog koda za autentikaciju. Heširaj lozinke sa Argon2id ili bcrypt. Dodaj resetovanje lozinke putem emaila sa vezom za jednokratnu upotrebu koja ističe za jedan sat. Čuvaj sesije u bezbednim HttpOnly kolačićima. Zaštiti /dashboard i svaku /api rutu tako da ih mogu koristiti samo prijavljeni korisnici, i osiguraj da korisnici vide samo svoje projekte. Dodaj ulogu "admin" koja može da vidi sve korisnike; samo administratori mogu da dođu do /admin, proverenu na serveru.
Zatim testirajte: registrujte se, odjavite se, prijavite se, resetujte lozinku, pokušajte privatni URL dok ste odjavljeni i pokušajte zapis drugog korisnika.
Česte greške u prijavi pravljenoj uz AI
- Zaštita samo na stranici. Stranica preusmerava odjavljene korisnike, ali API vraća podatke svakome.
- Tajne u pregledaču. Client secret za OAuth i administratorski ključevi provajdera autentikacije pripadaju serveru.
- Pomešani URL pregleda i živog sajta. Redirect URI Googlea ili link za resetovanje u emailu pokazuje na pregled, pa prijava pukne nakon objavljivanja.
- Bez verifikacije emaila. Svako može da se registruje kao neko@firma.com. Verifikujte email pre nego što odobrite bilo šta vezano za tu adresu.
- Testiranje samo ispravnog toka. Probajte pogrešne lozinke, istekle veze i drugi nalog.
Dodavanje prijave u Mythexu
U Mythexu, prijava za korisnike vaše aplikacije je nešto što dodajete svojoj aplikaciji — odvojeno je od vašeg Mythex naloga. Mythex ne pruža ugrađen proizvod za autentikaciju, pa donosite biblioteku ili provajdera i njihove ključeve:
- Izaberite pristup — na primer email i lozinku sačuvane u vašoj bazi ili SDK hostovanog provajdera.
- Ako čuvate korisnike sami, aplikaciji treba baza; zatražite je u chatu ili koristite
/database. - Ključeve provajdera stavite u tajne projekta (
/secretsili podešavanja projekta). - Koristite prompt kao gore, pa testirajte u Preview-u. Za prijavu preko Googlea dodajte URI-je za preusmeravanje i za pregled i za objavljenu adresu.
Pogledajte Dodavanje prijave u aplikaciju u dokumentaciji. Ako pravite plaćeni proizvod, kako napraviti SaaS MVP pokriva naloge i naplatu zajedno.
Pitanja
Koja je najlakša prijava za dodavanje aplikaciji?
Korišćenje hostovanog provajdera autentikacije ili dobro održavane biblioteke za autentikaciju obično je najlakše i najbezbednije, jer su sesije, čuvanje lozinki i resetovanje već rešeni. Prijava preko Googlea je najmanje zahtevna opcija za korisnike koji imaju Google naloge.
Da li su magične veze bezbednije od lozinki?
Uklanjaju ponovnu upotrebu lozinki i slabe lozinke, ali rizik prebacuju na korisnikov email nalog. Veze treba da isteknu brzo i da rade samo jednom. Za većinu malih aplikacija to je razumen izbor, često ponuđen uz prijavu preko Googlea.
Da li mi treba Googleovo odobrenje da dodam prijavu preko Googlea?
Ako tražite samo osnovne podatke za prijavu (ime, email i profil), Google kaže da verifikacija nije obavezna, ali i dalje podešavate ekran saglasnosti i OAuth klijent. Traženje pristupa osetljivim podacima, poput Gmaila ili Drajva, zahteva Googlovu verifikaciju aplikacije.
Koja je razlika između prijave i dozvola?
Prijava (autentikacija) potvrđuje ko je korisnik. Dozvole (autorizacija) određuju šta taj korisnik sme da vidi i radi. Aplikaciji su potrebne obe, a dozvole se moraju proveravati na serveru za svaki zahtev.