Vodiči

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

MetodKako radiPrednostiMane
Email i lozinkaKorisnik pravi lozinku; vi čuvate njen hešPoznato, radi bez emailaResetovanje lozinki, ponovna upotreba, curenja; morate bezbedno čuvati lozinke
Magična vezaKorisnik unese email, klikne vezu koju mu pošaljeteNema lozinki za čuvanje ili zaboravljanjeZavisi od isporuke emaila; prijava je sporija
Jednokratni kodKorisnik unese email, otkuca kod od 6 cifaraRadi kada se veze otvore u pogrešnom pregledačuIsta zavisnost od emaila
Društvena / OAuth (Google, Apple, GitHub, Microsoft)Drugi provajder potvrđuje ko je korisnikNajbrže za korisnike; nema lozinke za vas da čuvateKorisnici 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:

  1. Napravite ili izaberite projekat i popunite stranicu Branding — šta korisnici vide na ekranu saglasnosti (naziv aplikacije, email za podršku, logo).
  2. Na stranici Clients napravite klijent tipa "Web application".
  3. 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.
  4. 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ći http naspram https, 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 localhost tokom razvoja.
  • Parametar state treba 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?

PristupPrimeriKada odgovara
Hostovani provajder autentikacijeUsluge koje hostuju prijavu, upravljanje korisnicima i sesije umesto vasŽelite da prijava radi brzo, uz manje bezbednosne odgovornosti
Biblioteka za autentikaciju u aplikacijiBiblioteke 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:

UlogaTipične dozvole
PosetilacVidi javne stranice
Član / kupacVidi i menja samo svoje zapise
OsobljeVidi sve zapise svog tima ili preduzeća; ne može da menja podešavanja ili naplatu
Vlasnik / administratorSve, 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) i SameSite
  • 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:

  1. Izaberite pristup — na primer email i lozinku sačuvane u vašoj bazi ili SDK hostovanog provajdera.
  2. Ako čuvate korisnike sami, aplikaciji treba baza; zatražite je u chatu ili koristite /database.
  3. Ključeve provajdera stavite u tajne projekta (/secrets ili podešavanja projekta).
  4. 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.

Mythex · Pricing · Pravite bilo šta uz AI · Šabloni za sajtove i aplikacije · Mythex u poređenju · Rečnik pojmova za pravljenje aplikacija uz AI · Besplatni alati za pravljenje aplikacija uz AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)