Ինչպես ավելացնել մուտք ձեր հավելվածին. գաղտնաբառեր, magic link-եր, Google և դերեր

Հավելվածին մուտք ավելացնելու համար ընտրեք մեթոդ՝ էլ․ փոստ և գաղտնաբառ, magic link (մեկանգամյա մուտքի հղում, որն ուղարկվում է էլ․ փոստով) կամ «Sign in with Google», և իրագործեք այն ապացուցված աութենտիֆիկացիայի գրադարանով կամ հոսթված մատակարարով, այլ ոչ թե զրոյից։ Ապա որոշեք, թե յուրաքանչյուր տեսակի օգտատեր ինչ կարող է անել (դերեր), և պարտադրեք դա սերվերի վրա յուրաքանչյուր էջի և API հարցման համար։ Սեսիաները պետք է օգտագործեն անվտանգ cookie-ներ, լրանան և ճիշտ ավարտվեն դուրս գալիս։

Այս ուղեցույցը անցնում է յուրաքանչյուր ընտրության և այն մանրամասների միջով, որոնք աշխատող մուտքը տարբերում են անվտանգից։ Հայեցակարգերի համար տես ինչ է աութենտիֆիկացիան։

Նախ որոշեք՝ արդյոք մուտք ընդհանրապես պետք է

Մուտքը հարմարավետության խնդիր է ստեղծում և պատասխանատվություն։ Այն պետք է, երբ.

• Օգտատերերն ունեն անձնական տվյալներ (իրենց ամրագրումները, փաստաթղթերը, հաշիվ-ապրանքագրերը)
• Օգտատերերը կարող են փոխել այն, ինչ մյուսները կտեսնեն
• Դուք վճարովի մուտք եք գանձում
• Տարբեր մարդիկ տարբեր թույլտվություններ են պետք (սեփականատեր, աշխատակից, հաճախորդ)

Այն գուցե չի պետք մարքեթինգային կայքի, հանրային ցուցակի կամ այն ձևի համար, որը պարզապես ուղարկում է ձեզ նամակ։ Ցուցակագրման նախնական գրանցումը հաշիվներ չի պահանջում․ էլ․ փոստի դաշտը բավական է։

Չորս տարածված մուտքի մեթոդ

Շատ հավելվածներ համատեղում են երկուսը։ Google մուտքը և էլ․ փոստի magic link-ը տարածված զույգ է, որը ծածկում է մարդկանց մեծ մասին՝ առանց որևէ գաղտնաբառ պահելու։

Էլ․ փոստ և գաղտնաբառ

Եթե առաջարկում եք գաղտնաբառեր, սրանք անփոխարինելի են.

• Հեշավորեք գաղտնաբառերը դանդաղ գաղտնաբառ-հեշավորման ալգորիթմով։ OWASP-ի գաղտնաբառերի պահպանման ուղեցույցը խորհուրդ է տալիս Argon2id, իսկ այլընտրանքներ են scrypt-ը, bcrypt-ը կամ PBKDF2-ը։ Երբեք մի պահեք գաղտնաբառեր պարզ տեքստով կամ արագ ընդհանուր հեշով։
• Գաղտնաբառի վերականգնումը օգտագործում է պատահական, մեկանգամյա հղում, որը լրանում է և ուղարկվում է ստուգված էլ․ փոստին։
• Մի բացահայտեք, թե որ էլ․ փոստերն ունեն հաշիվներ։ «Եթե այդ էլ․ փոստը գրանցված է, մենք ուղարկել ենք վերականգնման հղում» ավելի լավ է, քան «Հաշիվ չի գտնվել»։
• Սահմանափակեք արագությունը մուտքի և վերականգնման փորձերի համար, որպեսզի դանդաղեցնեք գաղտնաբառերի կռահումը։
• Թույլ տվեք երկար գաղտնաբառեր և գաղտնաբառերի կառավարիչներ․ բաց թողեք այն կանոնները, որոնք պարտադրում են տարօրինակ նիշերի խառնուրդ։

Magic link-եր և մեկանգամյա կոդեր

Magic link-ը օգտատիրոջը ուղարկված մուտքի հղում է։ Դրա սեղմումը մուտք է գործում օգտատիրոջը։ Մեկանգամյա կոդը նույն գաղափարն է, բայց մուտքագրվում է, ոչ թե սեղմվում։

• Հղումներն ու կոդերը արագ են լրանում և աշխատում են մեկ անգամ։
• Հղումը պետք է մուտք գործի օգտատիրոջը այն սարքի վրա, որտեղ նա սեղմել է, և նշանը չպետք է մնա լոգերում կամ analytics գործիքներում։
• Ձեզ պետք է հուսալի էլ․ փոստի ուղարկում․ տես ինչպես ուղարկել էլ․ նամակներ ձեր հավելվածից։ Փորձարկեք Gmail-ով և Outlook-ով, և ստուգեք spam թղթապանակը։

Sign in with Google (և այլ OAuth մատակարարներ)

«Sign in with Google»-ը օգտագործում է OAuth և OpenID Connect․ Google-ը հաստատում է, թե ով է օգտատերը, և ասում է ձեր հավելվածին նրա էլ․ փոստը և անունը։ Կարգավորումը, սեպտեմբեր 2026-ի դրությամբ, կատարվում է Google Cloud Console-ի Google Auth Platform բաժնում։

1. Ստեղծեք կամ ընտրեք նախագիծ և լրացրեք Branding էջը՝ այն, ինչ տեսնում են օգտատերերը համաձայնության էկրանին (հավելվածի անուն, աջակցության էլ․ փոստ, լոգո)։
2. Clients էջում ստեղծեք «Web application» տիպի client։
3. Ավելացրեք authorized JavaScript origins-ը և redirect URI-ները՝ հենց այն հասցեները, որտեղ աշխատում է ձեր հավելվածը և որոնց Google-ը վերադարձնում է օգտատիրոջը մուտքից հետո։
4. Պահեք client ID-ը և client secret-ը ձեր հավելվածի գաղտնիքներում։

Բաներ, որոնք սովորաբար սխալվում են՝ ըստ Google-ի OAuth փաստաթղթերի.

• redirect_uri_mismatch․ redirect հասցեն պետք է ճշգրիտ համընկնի, ներառյալ http-ը կամ https-ը, մեծատառերը և վերջի սլաշը։ Ավելացրեք մեկը ձեր նախադիտման հասցեի և մեկը ձեր կենդանի դոմեյնի համար։
• HTTPS է պարտադիր․ redirect URI-ները պետք է օգտագործեն HTTPS, բացի զարգացման ընթացքում localhost-ից։
• state պարամետրը պետք է ստուգվի վերադարձի ժամանակ, որպեսզի պաշտպանվեք cross-site request forgery-ից։ Լավ գրադարանները դա անում են ձեզ համար։

Եթե պահանջում եք միայն մուտքի հիմնական տեղեկությունները (անուն, էլ․ փոստ, պրոֆիլ), Google-ը ասում է, որ հավելվածի ստուգումը պարտադիր չէ։ Օգտատերերի Gmail-ին, Drive-ին կամ Calendar-ին մուտք պահանջելը տարբեր է և պահանջում է ստուգում։

Կառուցե՞լ, թե օգտագործել մատակարար

Առաջին երկու տարբերակներից երկուսն էլ խելամիտ են։ Հոսթված մատակարարները ավելին են անում ձեզ համար, բայց ավելացնում են կախվածություն և երբեմն արժեն ակտիվ օգտատիրոջ հաշվով․ գները ստուգեք նրանց կայքերում։ Գրադարանները օգտատերերը պահում են ձեր տվյալների բազայում, բայց ավելի շատ բան են թողնում ձեզ՝ ճիշտ կարգավորելու համար։ Ինչ էլ ընտրեք, խնդրեք AI-ին օգտագործել այն, այլ ոչ թե ձեռքով գրել գաղտնաբառի կամ սեսիայի տրամաբանություն։

Դերեր և թույլտվություններ

Մուտքը ձեզ ասում է, թե ով է մարդը, թույլտվությունները որոշում են, թե ինչ կարող է անել։ Սկզբում պարզ պահեք.

Ավելի կարևոր են դերերի անուններից կանոնները.

• Ստուգեք սերվերի վրա, ամեն անգամ։ Կոճակը էջում թաքցնելը ոչ ոքի չի կանգնեցնում API-ին ուղղակիորեն կանչելուց։
• Սահմանափակեք սեփականատիրոջ կողմից։ Անդամը, որ բերում է «ամրագրում 123», պետք է այն ստանա միայն եթե այն իրն է։
• Օգտատերերը չեն կարող իրենց առաջ տանել։ Անտեսեք դերի դաշտերը, որոնք ուղարկվում են բրաուզերից պրոֆիլի թարմացումների ժամանակ։
• Լռելյայն՝ առանց մուտքի։ Նոր երթուղիները պետք է պահանջեն մուտք, եթե դուք չեք որոշել այլ կերպ։

Փորձարկեք երկու հաշվով․ մտեք մեկով, նշեք գրառման ID-ն, մտեք մյուսով և փորձեք բացել այն։ Մեր անվտանգության ստուգաթերթը ունի ամբողջական փորձարկումը։

Սեսիայի անվտանգություն

Մուտքից հետո հավելվածը հիշում է օգտատիրոջը սեսիայով՝ սովորաբար cookie-ով։ OWASP-ի սեսիաների կառավարման ուղեցույցը խորհուրդ է տալիս.

• Սեսիայի cookie-ները սահմանված են Secure (միայն HTTPS), HttpOnly (անընթեռնելի էջի սկրիպտների համար) և SameSite
• Նոր սեսիայի ID է տրվում մուտքի ժամանակ, և նորից՝ երբ արտոնությունները փոխվում են
• Անգործության ժամանակի սահման և բացարձակ առավելագույն կյանքի տևողություն, որոնք պարտադրվում են սերվերի վրա
• Դուրս գալը ավարտում է սեսիան սերվերի վրա, ոչ միայն cookie-ն ջնջում
• Սեսիաները անվավեր են դառնում, երբ օգտատերը փոխում է գաղտնաբառը

Բրաուզերի local storage-ում մուտքի նշանները պահելը տարածված է ձեռնարկներում, բայց բացահայտում է դրանք էջում աշխատող ցանկացած սկրիպտի առաջ․ անվտանգ cookie-ները սովորաբար ավելի լավ լռելյայն են վեբ հավելվածների համար։

Հուշում, որը ծածկում է հիմունքները

Ավելացրու օգտատերերի հաշիվներ այս հավելվածին։ Օգտատերերը կարող են գրանցվել և մուտք գործել էլ․ փոստով և գաղտնաբառով, կամ Google-ով։ Օգտագործիր [գրադարան կամ մատակարար] և ոչ թե աութենտիֆիկացիայի հատուկ կոդ։ Գաղտնաբառերը հեշավորիր Argon2id-ով կամ bcrypt-ով։ Ավելացրու գաղտնաբառի վերականգնում էլ․ փոստով՝ մեկանգամյա հղումով, որը լրանում է մեկ ժամից։ Սեսիաները պահիր անվտանգ, միայն HttpOnly cookie-ներում։ Պաշտպանիր /dashboard-ը և յուրաքանչյուր /api երթուղի, որպեսզի միայն մուտք գործած օգտատերերը կարողանան օգտագործել դրանք, և համոզվիր, որ օգտատերերը տեսնում են միայն իրենց նախագծերը։ Ավելացրու «admin» դեր, որը կարող է տեսնել բոլոր օգտատերերին. միայն ադմինները կարող են մտնել /admin, և դա ստուգվի սերվերի վրա։

Հետո փորձարկեք․ գրանցվեք, դուրս եկեք, մտեք, վերականգնեք գաղտնաբառը, փորձեք մասնավոր URL-ը դուրս գալուց հետո և մեկ այլ օգտատիրոջ գրառումը։

Սովորական սխալներ AI-ով կառուցված մուտքում

• Պաշտպանությունը միայն էջում։ Էջը վերահղում է դուրս եկած օգտատերերին, բայց API-ը տվյալներ է վերադարձնում յուրաքանչյուրին։
• Գաղտնիքները բրաուզերում։ OAuth client secret-ները և աութենտիֆիկացիայի մատակարարի ադմին բանալիները պետք է լինեն սերվերի վրա։
• Նախադիտման և կենդանի URL-ները խառնված։ Google-ի redirect URI-ը կամ վերականգնման նամակի հղումը ցույց է տալիս նախադիտմանը, ուստի մուտքը կոտրվում է հրապարակելուց հետո։
• Առանց էլ․ փոստի ստուգման։ Ցանկացած ոք կարող է գրանցվել որպես anyone@company.com։ Ստուգեք էլ․ փոստը նախքան որևէ բան տալը, որ կապված է այդ հասցեի հետ։
• Միայն հաջող ճանապարհի փորձարկում։ Փորձեք սխալ գաղտնաբառեր, լրացած հղումներ և երկրորդ հաշիվ։

Մուտքի ավելացումը Mythex-ում

Mythex-ում ձեր հավելվածի օգտատերերի մուտքը այն է, ինչ դուք ավելացնում եք ձեր հավելվածին. այն առանձին է ձեր Mythex հաշվից։ Mythex-ը չի տրամադրում ներկառուցված աութենտիֆիկացիայի արտադրանք, ուստի դուք բերում եք աութենտիֆիկացիայի գրադարան կամ մատակարար և նրա բանալիները.

1. Ընտրեք մոտեցում, օրինակ՝ էլ․ փոստ և գաղտնաբառ ձեր տվյալների բազայում կամ հոսթված մատակարարի SDK։
2. Եթե օգտատերերին ինքներդ եք պահում, հավելվածին տվյալների բազա է պետք․ պահանջեք այն չաթում կամ օգտագործեք /database։
3. Մատակարարի բանալիները դրեք նախագծի գաղտնիքներում (/secrets կամ նախագծի կարգավորումներ)։
4. Օգտագործեք վերևի նման հուշում և փորձարկեք Preview-ում։ Google մուտքի համար ավելացրեք redirect URI-ներ և՛ ձեր նախադիտման, և՛ հրապարակված հասցեի համար։

Տես Ավելացնել մուտք ձեր հավելվածին փաստաթղթերում։ Եթե կառուցում եք վճարովի արտադրանք, ինչպես կառուցել SaaS MVP ուղեցույցը ընդգրկում է հաշիվները և վճարումները միասին։

Հարցեր