Kā pievienot pieteikšanos savai lietotnei: paroles, maģiskās saites, Google un lomas

Lai pievienotu pieteikšanos lietotnei, izvēlies metodi — e-pasts un parole, maģiskās saites (vienreizēja pieteikšanās saite, ko nosūta e-pastā) vai „Pieteikties ar Google” — un ievieso to ar pārbaudītu autentifikācijas bibliotēku vai hostētu nodrošinātāju, nevis no nulles. Pēc tam izlem, ko katra veida lietotājs drīkst darīt (lomas), un nodrošini to serverī katrai lapai un API pieprasījumam. Sesijām jāizmanto drošas sīkdatnes, tām jābeidzas un jāizbeidzas pareizi, kad lietotājs izrakstās.

Šajā ceļvedī aplūkota katra izvēle un detaļas, kas atšķir darbojošos pieteikšanos no drošas. Pamatjēdzieniem skat. kas ir autentifikācija.

Vispirms izlem: vai pieteikšanās vispār vajag?

Pieteikšanās pievieno berzi un atbildību. Tā vajag, kad:

• Lietotājiem ir privāti dati (viņu rezervācijas, dokumenti, rēķini)
• Lietotāji var mainīt lietas, ko redzēs citi
• Tu iekasē maksu par piekļuvi
• Dažādiem cilvēkiem vajag dažādas atļaujas (īpašnieks, darbinieks, klients)

Tā, iespējams, nav vajadzīga mārketinga vietnei, publiskam katalogam vai veidlapai, kas tikai nosūta tev e-pastu. Gaidītāju sarakstam kontu nevajag; pietiek ar e-pasta lauku.

Četras biežākās pieteikšanās metodes

Daudzas lietotnes apvieno divas: pieteikšanās ar Google un e-pasta maģiskās saites ir populārs pāris, kas aptver lielāko daļu cilvēku, neglabājot nevienu paroli.

E-pasts un parole

Ja piedāvā paroles, šie ir neapspriežami nosacījumi:

• Jauc paroles ar lēnu paroļu jaukšanas algoritmu. OWASP paroļu glabāšanas vadlīnijas iesaka Argon2id, alternatīvas ir scrypt, bcrypt vai PBKDF2. Nekad neglabā paroles tīrā tekstā vai ar ātru vispārīgu jaucējfunkciju.
• Paroļu atjaunošana izmanto nejaušu, vienreizēju saiti, kas beidzas, nosūtītu uz pārbaudītu e-pastu.
• Neatklāj, kuriem e-pastiem ir konti. „Ja šis e-pasts ir reģistrēts, mēs esam nosūtījuši atjaunošanas saiti” ir labāk nekā „Konts nav atrasts”.
• Ierobežo pieteikšanās un atjaunošanas mēģinājumu biežumu, lai palēninātu paroļu minēšanu.
• Atļauj garas paroles un paroļu pārvaldniekus; izlaid noteikumus, kas piespiež dīvainus rakstzīmju sajaukumus.

Maģiskās saites un vienreizēji kodi

Maģiskā saite ir pieteikšanās saite, ko nosūta lietotājam e-pastā. Uz tās noklikšķinot, lietotājs tiek pieteikts. Vienreizējs kods ir tā pati ideja, bet to ieraksta, nevis noklikšķina.

• Saitēm un kodiem ātri beidzas derīgums, un tie darbojas tikai vienu reizi.
• Saitei jāpieraksta lietotājs ierīcē, kur uz tās noklikšķināts, un marķieris nedrīkst palikt žurnālos vai analītikas rīkos.
• Vajag uzticamu e-pasta sūtīšanu — skat. kā sūtīt e-pastus no lietotnes. Pārbaudi ar Gmail un Outlook un pārskati surogātpasta mapes.

Pieteikšanās ar Google (un citi OAuth nodrošinātāji)

„Pieteikties ar Google” izmanto OAuth un OpenID Connect: Google apstiprina, kas ir lietotājs, un pasaka tavai lietotnei viņa e-pastu un vārdu. Iestatīšana 2026. gada septembrī notiek Google Cloud Console sadaļā Google Auth Platform:

1. Izveido vai izvēlies projektu un aizpildi lapu Branding — ko lietotāji redz piekrišanas ekrānā (lietotnes nosaukums, atbalsta e-pasts, logotips).
2. Lapā Clients izveido klientu ar tipu „Web application”.
3. Pievieno authorized JavaScript origins un redirect URIs — precīzās adreses, kurās darbojas tava lietotne un uz kurām Google pārsūta lietotājus pēc pieteikšanās.
4. Glabā klienta ID un klienta noslēpumu tavās lietotnes noslēpumos.

Lietas, kas bieži noiet greizi, saskaņā ar Google OAuth dokumentāciju:

• redirect_uri_mismatch: pārsūtīšanas adresei jāsakrīt precīzi, arī http pret https, lielo un mazo burtu un jebkuras beigu slīpsvītras dēļ. Pievieno vienu priekšskatījuma adresei un vienu savam dzīvajam domēnam.
• Nepieciešams HTTPS: pārsūtīšanas URI jālieto HTTPS, izņemot localhost izstrādes laikā.
• Parametrs state jāpārbauda atgriežoties, lai pasargātu no starpvietņu pieprasījumu viltošanas. Labas bibliotēkas to dara automātiski.

Ja pieprasi tikai pamata pieteikšanās informāciju (vārdu, e-pastu, profilu), Google saka, ka lietotnes verifikācija nav obligāta. Lietotāju Gmail, Drive vai Calendar piekļuves pieprasīšana ir cits gadījums un prasa verifikāciju.

Veidot pašam vai izmantot nodrošinātāju?

Abas pirmās iespējas ir saprātīgas. Hostētie nodrošinātāji tev daudz ko izdara paši, bet pievieno atkarību un dažreiz maksā par katru aktīvo lietotāju; pašreizējās cenas skat viņu vietnēs. Bibliotēkas glabā visu tavā datubāzē, bet vairāk jāiestata pareizi pašam. Ko arī izvēlies, lūdz AI to izmantot, nevis rakstīt paroļu vai sesiju loģiku ar rokām.

Lomas un atļaujas

Pieteikšanās pasaka, kas ir cilvēks. Atļaujas nosaka, ko viņš drīkst darīt. Sākumā turi to vienkāršu:

Noteikumi, kas svarīgāki par lomu nosaukumiem:

• Pārbaudi serverī katru reizi. Pogas paslēpšana lapā nepārtrauc ikvienu, kas tieši izsauc API.
• Ierobežo pēc īpašnieka. Dalībnieks, kas iegūst „rezervāciju 123”, to drīkst saņemt tikai tad, ja tā ir viņa.
• Lietotāji nevar paaugstināt sevi. Ignorē lomu laukus, kas nosūtīti no pārlūkprogrammas profila atjauninājumos.
• Noklusējums — nav piekļuves. Jaunajiem maršrutiem jāprasa pieteikšanās, ja vien nenolemj citādi.

Pārbaudi ar diviem kontiem: piesakies kā viens, pieraksti kāda ieraksta ID, piesakies kā otrs un mēģini to atvērt. Mūsu drošības kontrolsaraksts satur pilnu testu.

Sesijas drošība

Pēc pieteikšanās lietotne atceras lietotāju ar sesiju — parasti sīkdatni. OWASP sesiju pārvaldības vadlīnijas iesaka:

• Sesijas sīkdatnes iestatītas ar Secure (tikai HTTPS), HttpOnly (nelasāmas lapas skriptiem) un SameSite
• Jauns sesijas ID izsniegts pieteikšanās brīdī un atkal, kad mainās privilēģijas
• Dīkstāves noildze un absolūts maksimālais darbības laiks, ko izpilda serveris
• Izrakstīšanās, kas beidz sesiju serverī, nevis tikai izdzēš sīkdatni
• Sesijas tiek anulētas, kad lietotājs maina paroli

Pieteikšanās marķieru glabāšana pārlūkprogrammas localStorage ir izplatīta pamācībās, bet tā atklāj tos jebkuram skriptam, kas darbojas lapā; drošas sīkdatnes parasti ir labāks noklusējums tīmekļa lietotnēm.

Uzvedne, kas aptver svarīgāko

Pievieno šai lietotnei lietotāju kontus. Lietotāji var reģistrēties un pieteikties ar e-pastu un paroli vai ar Google. Izmanto [bibliotēka vai nodrošinātājs], nevis pašu rakstītu autentifikācijas kodu. Jauc paroles ar Argon2id vai bcrypt. Pievieno paroles atjaunošanu pa e-pastu ar vienreizēju saiti, kas beidzas pēc vienas stundas. Glabā sesijas drošās HttpOnly sīkdatnēs. Aizsargā /dashboard un katru /api maršrutu, lai tos var izmantot tikai pieteikušies lietotāji, un pārliecinies, ka lietotāji redz tikai savus projektus. Pievieno lomu „admin”, kas var redzēt visus lietotājus; tikai administratori var nokļūt /admin, pārbaudīts serverī.

Pēc tam pārbaudi: reģistrējies, izrakstīties, pieteikties, atjaunot paroli, mēģināt privātu URL izrakstījies un mēģināt citu lietotāja ierakstu.

Biežākās kļūdas MI veidotā pieteikšanās

• Aizsardzība tikai lapā. Lapa pāradresē izrakstījušos lietotājus, bet API atgriež datus ikvienam.
• Noslēpumi pārlūkprogrammā. OAuth klienta noslēpumi un autentifikācijas nodrošinātāja administratora atslēgas pieder serverim.
• Priekšskatījuma un dzīvo URL sajaukšana. Google pārsūtīšanas URI vai atjaunošanas e-pasta saite norāda uz priekšskatījumu, tāpēc pēc publicēšanas pieteikšanās nedarbojas.
• Nav e-pasta apstiprināšanas. Ikviens var reģistrēties kā anyone@company.com. Apstiprini e-pastu, pirms piešķir kaut ko, kas saistīts ar šo adresi.
• Testē tikai veiksmīgo ceļu. Pamēģini nepareizas paroles, beigušās saites un otru kontu.

Pieteikšanās pievienošana Mythex

Mythex lietotnē pieteikšanās tavas lietotnes lietotājiem ir kaut kas, ko pievieno savai lietotnei — tā ir atsevišķa no tava paša Mythex konta. Mythex nenodrošina iebūvētu autentifikācijas produktu, tāpēc ienes autentifikācijas bibliotēku vai nodrošinātāju un tā atslēgas:

1. Izvēlies pieeju — piemēram, e-pastu un paroli, ko glabā savā datubāzē, vai hostēta nodrošinātāja SDK.
2. Ja lietotājus glabā pats, lietotnei vajag datubāzi; pieprasi to tērzēšanā vai izmanto /database.
3. Ievieto nodrošinātāju atslēgas projekta noslēpumos (/secrets vai projekta iestatījumos).
4. Izmanto uzvedni, kā augstāk, un pārbaudi priekšskatījumā. Pieteikšanās ar Google gadījumā pievieno pārsūtīšanas URI gan priekšskatījuma, gan publicētajai adresei.

Skat. Pievienot pieteikšanos savai lietotnei dokumentācijā. Ja veido maksas produktu, kā izveidot SaaS MVP aplūko kontus un rēķinus kopā.

Jautājumi