Si të shtoni hyrjen në aplikacionin tuaj: fjalëkalime, lidhje magjike, Google dhe role

Për të shtuar hyrjen te një aplikacion, zgjidhni një metodë — email dhe fjalëkalim, lidhje magjike (një lidhje hyrjeje për një herë që dërgohet me email), ose "Sign in with Google" — dhe zbatojeni me një bibliotekë autentikimi të provuar ose me një ofrues të hostuar, në vend që ta ndërtoni nga zero. Pastaj vendosni çfarë mund të bëjë secili lloj përdoruesi (role), dhe zbatojeni këtë në server për çdo faqe dhe çdo kërkesë API. Sesionet duhet të përdorin cookie-t e sigurta, të skadojnë, dhe të mbyllen si duhet kur përdoruesi del.

Ky udhëzues shkon përmes çdo zgjedhjeje dhe detajeve që e dallojnë një hyrje që funksionon nga një hyrje e sigurt. Për konceptet pas saj, shihni çfarë është autentikimi.

Vendosni fillimisht: a ju duhet fare hyrje?

Hyrja shton friksion dhe përgjegjësi. Ju duhet kur:

Përdoruesit kanë të dhëna private (rezervimet, dokumentet, faturat e tyre)
Përdoruesit mund të ndryshojnë gjëra që të tjerët do t'i shohin
Ju paguhet për akses
Njerëz të ndryshëm kanë leje të ndryshme (pronari kundrejt stafit kundrejt klientit)

Ndoshta nuk ju duhet për një faqe marketingu, një drejtori publike, ose një formular që thjesht ju dërgon një email. Një listë pritjeje nuk ka nevojë për llogari; një fushë email mjafton.

Katër metodat e zakonshme të hyrjes

Metoda	Si funksionon	Të mirat	Të metat
Email + fjalëkalim	Përdoruesi krijon një fjalëkalim; ju ruani një hash të tij	E njohur, funksionon pa email	Rivendosje fjalëkalimi, ripërdorim, shkelje; duhet të ruani fjalëkalimet në mënyrë të sigurt
Lidhje magjike	Përdoruesi shkruan email-in, klikon një lidhje që i dërgoni	Nuk ka fjalëkalime për të ruajtur ose harruar	Varet nga dërgimi i email-it; hyrja është më e ngadaltë
Kod një herë	Përdoruesi shkruan email-in, shkruan një kod 6-shifror	Funksionon kur lidhjet hapen në shfletuesin e gabuar	Po e njëjta varësi nga email-i
Social / OAuth (Google, Apple, GitHub, Microsoft)	Një ofrues tjetër konfirmon kush është përdoruesi	Më e shpejta për përdoruesit; nuk ruani fjalëkalim	Përdoruesit duhet ta kenë atë llogari; konfigurimi bëhet te ofruesi

Shumë aplikacione kombinojnë dy metoda: hyrja me Google plus lidhjet magjike me email është një çift i njohur që mbulon shumicën e njerëzve pa ruajtur asnjë fjalëkalim.

Email dhe fjalëkalim

Nëse ofroni fjalëkalime, këto janë të domosdoshme:

Hash-oni fjalëkalimet me një algoritëm të ngadaltë hash-imi. Udhëzimi i OWASP për ruajtjen e fjalëkalimeve rekomandon Argon2id, me scrypt, bcrypt ose PBKDF2 si alternativa. Mos ruani kurrë fjalëkalime si tekst të qartë ose me një hash të shpejtë të përgjithshëm.
Rivendosjet e fjalëkalimit përdorin një lidhje të rastësishme, për një përdorim të vetëm, që skadon, e dërguar te email-i i verifikuar.
Mos zbuloni cilat email-e kanë llogari. "Nëse ky email është i regjistruar, kemi dërguar një lidhje rivendosjeje" është më mirë sesa "Nuk u gjet llogari".
Kufizoni shpejtësinë e tentativave të hyrjes dhe rivendosjes për të ngadalësuar hamendësimin e fjalëkalimeve.
Lejoni fjalëkalime të gjata dhe menaxherët e fjalëkalimeve; hiqni rregullat që detyrojnë përzierje të çuditshme karakteresh.

Lidhje magjike dhe kode një herë

Një lidhje magjike është një lidhje hyrjeje e dërguar me email te përdoruesi. Klikimi i saj e fut përdoruesin. Një kod një herë është e njëjta ide, por shkruhet në vend që të klikohet.

Lidhjet dhe kodet skadojnë shpejt dhe funksionojnë vetëm një herë.
Lidhja duhet ta fusë përdoruesin në pajisjen ku u klikua, dhe token-i nuk duhet të qëndrojë në regjistrime ose mjete analitike.
Ju duhet dërgim i besueshëm email-esh — shihni si të dërgoni email-e nga aplikacioni juaj. Testoni me Gmail dhe Outlook, dhe kontrolloni dosjet e spam-it.

"Sign in with Google" përdor OAuth dhe OpenID Connect: Google konfirmon kush është përdoruesi dhe i thotë aplikacionit tuaj email-in dhe emrin e tij. Konfigurimi, si i shtatorit 2026, bëhet te seksioni Google Auth Platform në Google Cloud Console:

Krijoni ose zgjidhni një projekt, dhe plotësoni faqen Branding — çfarë shohin përdoruesit në ekranin e pëlqimit (emri i aplikacionit, email-i i mbështetjes, logoja).
Te faqja Clients, krijoni një klient të tipit "Web application".
Shtoni authorized JavaScript origins dhe redirect URIs — adresat e sakta ku funksionon aplikacioni juaj dhe ku Google i kthen përdoruesit pas hyrjes.
Ruani client ID-në dhe client secret-in te sekretet e aplikacionit tuaj.

Gjërat që shpesh shkojnë keq, sipas dokumentacionit OAuth të Google:

redirect_uri_mismatch: adresa e redirect-it duhet të përputhet saktë, përfshi http kundrejt https, shkronjat e mëdha dhe një slash në fund. Shtoni një për adresën tuaj të pamjes paraprake dhe një për domenin tuaj të drejtpërdrejtë.
Kërkohet HTTPS: redirect URI-t duhet të përdorin HTTPS, me përjashtim të localhost gjatë zhvillimit.
Parametri state duhet kontrolluar kur kthehet përdoruesi, për të mbrojtur nga kërkesat e falsifikuara ndër-sajt. Bibliotekat e mira e bëjnë këtë për ju.

Nëse kërkoni vetëm informacion bazë hyrjeje (emri, email, profili), Google thotë se verifikimi i aplikacionit nuk është i detyrueshëm. Kërkesa për akses në Gmail, Drive ose Calendar të përdoruesve është e ndryshme dhe kërkon verifikim.

Ndërtoni vetë apo përdorni një ofrues?

Qasja	Shembuj	Kur përshtatet
Ofrues autentikimi i hostuar	Shërbime që hostojnë hyrjen, menaxhimin e përdoruesve dhe sesionet për ju	Doni që hyrja të funksionojë shpejt, me më pak përgjegjësi sigurie
Bibliotekë autentikimi në aplikacion	Biblioteka me burim të hapur për kornizën tuaj	Doni që përdoruesit të jenë në bazën tuaj të të dhënave dhe pa tarifa për përdorues
Ndërtoni vetë	—	Pothuajse kurrë. Ka shumë detaje delikate

Të dy të parat janë të arsyeshme. Ofruesit e hostuar trajtojnë më shumë për ju, por shtojnë një varësi dhe ndonjëherë kushtojnë sipas përdoruesit aktiv; kontrolloni çmimet aktuale në faqet e tyre. Bibliotekat mbajnë gjithçka në bazën tuaj, por lënë më shumë për t'u konfiguruar saktë nga ju. Cilado që zgjidhni, kërkojani AI-së ta përdorë atë në vend që të shkruajë vetë logjikën e fjalëkalimeve ose sesioneve.

Rolet dhe lejet

Hyrja tregon kush është dikush. Lejet vendosin çfarë mund të bëjë. Mbajeni të thjeshtë në fillim:

Roli	Lejet tipike
Vizitor	Shikon faqet publike
Anëtar / klient	Shikon dhe ndryshon regjistrimet e veta
Staf	Shikon të gjitha regjistrimet e ekipit ose biznesit të vet; nuk mund të ndryshojë cilësimet ose faturimin
Pronar / administrator	Çdo gjë, përfshi përdoruesit dhe faturimin

Rregullat që kanë më shumë rëndësi se emrat e roleve:

Kontrolloni në server, çdo herë. Fshehja e një butoni në faqe nuk e ndalon askënd të thërrasë API-n direkt.
Kufizoni sipas pronarit. Një anëtar që merr "rezervimi 123" duhet ta marrë vetëm nëse është i tij.
Përdoruesit nuk mund të promovojnë veten. Injoroni fushat e rolit të dërguara nga shfletuesi në përditësimet e profilit.
Parazgjedhja është pa akses. Rrugët e reja duhet të kërkojnë hyrje, përveç nëse vendosni ndryshe.

Testojeni me dy llogari: hyni me njërën, shënoni ID-në e një regjistrimi, pastaj hyni me tjetrën dhe provoni ta hapni. Lista e sigurisë ka testin e plotë.

Siguria e sesionit

Pas hyrjes, aplikacioni e njeh përdoruesin me një sesion — zakonisht një cookie. Udhëzimi i OWASP për menaxhimin e sesioneve rekomandon:

Cookie-t e sesionit të vendosur me Secure (vetëm HTTPS), HttpOnly (të palexueshëm nga skriptet e faqes) dhe SameSite
Një ID e re sesioni e lëshuar kur hyn, dhe përsëri kur ndryshojnë privilegjet
Një kohë joaktiviteti dhe një jetëgjatësi maksimale absolute, të zbatuara në server
Dalja që e mbyll sesionin në server, jo vetëm fshin cookie-n
Sesionet anulohen kur përdoruesi ndryshon fjalëkalimin

Ruajtja e token-ave të hyrjes në local storage të shfletuesit është e zakonshme në tutoriale, por i ekspozon ata ndaj çdo skripti që ekzekutohet në faqe; cookie-t e sigurta zakonisht janë zgjedhja më e mirë për aplikacionet web.

Një kërkesë që mbulon thelbin

Shto llogari përdoruesish te ky aplikacion. Përdoruesit regjistrohen dhe hyjnë me email dhe fjalëkalim, ose me Google. Përdor [bibliotekë ose ofrues] në vend të kodit të autentikimit me dorë. Hash-o fjalëkalimet me Argon2id ose bcrypt. Shto rivendosje fjalëkalimi me email, me një lidhje për një përdorim të vetëm që skadon pas një ore. Mbaj sesionet në cookie-t e sigurta HttpOnly. Mbroj /dashboard dhe çdo rrugë /api, që vetëm përdoruesit e kyçur t'i përdorin, dhe sigurohu që përdoruesit mund të shohin vetëm projektet e tyre. Shto një rol "admin" që mund të shohë të gjithë përdoruesit; vetëm administratorët mund të hyjnë në /admin, e kontrolluar në server.

Pastaj testoni: regjistrohuni, dilni, hyni, rivendosni fjalëkalimin, provoni një URL private kur jeni jashtë, dhe provoni regjistrimin e një përdoruesi tjetër.

Gabimet më të shpeshta në hyrjen e ndërtuar me AI

Mbrojtja vetëm në faqe. Faqja i ridrejton përdoruesit jashtë, por API-ja u kthen të dhëna kujtdo.
Sekrete në shfletues. Sekretet e klientit OAuth dhe çelësat admin të ofruesit të autentikimit i përkasin serverit.
Përzierje e URL-ve të pamjes paraprake dhe të drejtpërdrejtë. Redirect URI i Google ose lidhja e email-it për rivendosje tregon te pamja paraprake, kështu që hyrja prishet pas publikimit.
Pa verifikim email-i. Kushdo mund të regjistrohet si anyone@company.com. Verifikoni email-in para se t'i jepni diçka të lidhur me atë adresë.
Testimi vetëm i rastit të suksesshëm. Provoni fjalëkalime të gabuara, lidhje të skaduara dhe një llogari të dytë.

Shtimi i hyrjes në Mythex

Në Mythex, hyrja për përdoruesit e aplikacionit tuaj është diçka që e shtoni te aplikacioni juaj — është veçmas nga llogaria juaj Mythex. Mythex nuk ofron një produkt autentikimi të integruar, prandaj sillni një bibliotekë ose ofrues autentikimi dhe çelësat e tij:

Zgjidhni një qasje — për shembull, email dhe fjalëkalim të ruajtur në bazën tuaj të të dhënave, ose SDK-në e një ofruesi të hostuar.
Nëse i ruani përdoruesit vetë, aplikacioni ka nevojë për një bazë të dhënash; kërkojeni në chat ose përdorni /database.
Vendosni çelësat e ofruesit te sekretet e projektit (/secrets ose cilësimet e projektit).
Përdorni një kërkesë si ajo më sipër, pastaj testoni në Preview. Për hyrjen me Google, shtoni redirect URI-t për pamjen tuaj paraprake dhe për adresën tuaj të publikuar.

Shihni Shto hyrjen në aplikacionin tuaj në dokumentacion. Nëse po ndërtoni një produkt me pagesë, si të ndërtoni një MVP SaaS mbulon llogaritë dhe faturimin bashkë.

Pyetje

Cila është hyrja më e lehtë për t'i shtuar një aplikacioni?

Përdorimi i një ofruesi autentikimi të hostuar ose i një biblioteke autentikimi të mirëmbajtur është zakonisht më i lehti dhe më i sigurti, sepse sesionet, ruajtja e fjalëkalimeve dhe rivendosjet janë të trajtuara. Sign in with Google është opsioni me më pak friksion për përdoruesit që kanë llogari Google.

A janë lidhjet magjike më të sigurta se fjalëkalimet?

Ato heqin ripërdorimin e fjalëkalimeve dhe fjalëkalimet e dobëta, por e zhvendosin rrezikun te llogaria email e përdoruesit. Lidhjet duhet të skadojnë shpejt dhe të funksionojnë vetëm një herë. Për shumicën e aplikacioneve të vogla janë një zgjedhje e arsyeshme, shpesh e ofruar bashkë me hyrjen me Google.

A më duhet miratim nga Google për të shtuar Sign in with Google?

Nëse kërkoni vetëm informacion bazë hyrjeje (emri, email dhe profili), Google thotë se verifikimi i aplikacionit nuk është i detyrueshëm, por prapë konfiguroni një ekran pëlqimi dhe një klient OAuth. Kërkesa për akses në të dhëna të ndjeshme, si Gmail ose Drive, kërkon verifikim të aplikacionit nga Google.

Cila është diferenca mes hyrjes dhe lejeve?

Hyrja (autentikimi) konfirmon kush është përdoruesi. Lejet (autorizimi) vendosin çfarë mund të shohë dhe bëjë ai përdorues. Një aplikacion ka nevojë për të dyjat, dhe lejet duhet të kontrollohen në server për çdo kërkesë.