როგორ დავამატოთ შესვლა თქვენს აპში: პაროლები, მაგიური ბმულები, Google და როლები

აპში შესვლის დასამატებლად აირჩიეთ მეთოდი — ელფოსტა და პაროლი, მაგიური ბმულები (ერთჯერადი შესვლის ბმული, რომელიც ელფოსტით მოდის) ან „Sign in with Google“ — და დანერგეთ იგი დამტკიცებული ავთენტიფიკაციის ბიბლიოთეკით ან ჰოსტირებული პროვაიდერით და არა ნულიდან. შემდეგ განსაზღვრეთ, რის გაკეთება შეუძლია მომხმარებლის თითოეულ ტიპს (როლები) და ეს სერვერზე აღასრულეთ ყოველი გვერდისა და API მოთხოვნისთვის. სესიები უნდა იყენებდეს უსაფრთხო ქუქი-ფაილებს, ვადაგასული იყოს და გამოსვლისას სწორად დასრულდეს.

ეს სახელმძღვანელო გადის თითოეულ არჩევანსა და იმ დეტალებს, რომლებიც სამუშაო შესვლას უსაფრთხო შესვლისგან განასხვავებს. ამ კონცეფციების შესახებ იხილეთ რა არის ავთენტიფიკაცია.

პირველ რიგში გადაწყვიტეთ: გჭირდებათ თუ არა შესვლა საერთოდ?

შესვლა ხახუნს და პასუხისმგებლობას ზრდის. საჭიროა, როცა:

• მომხმარებლებს აქვთ პირადი მონაცემები (მათი დაჯავშნები, დოკუმენტები, ინვოისები)
• მომხმარებლებს შეუძლიათ შეცვალონ ის, რაც სხვებმა უნდა ნახონ
• თქვენ ფასიანი წვდომა გაქვთ
• სხვადასხვა ადამიანს სხვადასხვა უფლებები სჭირდება (მფლობელი, თანამშრომელი, კლიენტი)

შესაძლოა არ დაგჭირდეთ მარკეტინგული საიტისთვის, საჯარო დირექტორიისთვის ან ფორმისთვის, რომელიც უბრალოდ ელფოსტას გიგზავნით. წინასწარი ჩანაწერის ფორმას ანგარიშები არ სჭირდება; საკმარისია ელფოსტის ველი.

ოთხი ხშირი შესვლის მეთოდი

ბევრი აპი ორს აერთიანებს: Google-ით შესვლა პლუს ელფოსტის მაგიური ბმული პოპულარული წყვილია, რომელიც უმეტეს ადამიანს ფარავს პაროლების შენახვის გარეშე.

ელფოსტა და პაროლი

თუ პაროლებს სთავაზობთ, ეს არაგადასადებია:

• პაროლები დაჰეშეთ ნელი პაროლის ჰეშირების ალგორითმით. OWASP-ის პაროლის შენახვის რეკომენდაცია არის Argon2id, ალტერნატივები — scrypt, bcrypt ან PBKDF2. პაროლები არასდროს შეინახოთ უბრალო ტექსტად ან სწრაფი ზოგადი ჰეშით.
• პაროლის აღდგენა იყენებს შემთხვევით, ერთჯერად, ვადაგასულ ბმულს, რომელიც გამოწმებულ ელფოსტაზე იგზავნება.
• არ გამოავლინოთ, რომელ ელფოსტებს აქვს ანგარიში. „თუ ეს ელფოსტა რეგისტრირებულია, აღდგენის ბმული გამოგზავნილია“ უკეთესია, ვიდრე „ანგარიში ვერ მოიძებნა“.
• შეზღუდეთ მცდელობები (rate-limit) შესვლასა და აღდგენაზე, რათა პაროლის გამოცნობა შენელდეს.
• დაუშვით გრძელი პაროლები და პაროლის მენეჯერები; ისეთი წესები, რომლებიც უცნაური სიმბოლოების შერევას აიძულებს, გამოტოვეთ.

მაგიური ბმულები და ერთჯერადი კოდები

მაგიური ბმული არის ელფოსტით გამოგზავნილი შესვლის ბმული. მასზე დაწკაპუნება მომხმარებელს შესვლაში ატარებს. ერთჯერადი კოდი იგივე იდეაა, მხოლოდ დაწკაპუნების ნაცვლად იწერება.

• ბმულები და კოდები სწრაფად ვადაგასულდება და ერთხელ იმუშავებს.
• ბმულმა მომხმარებელი იმავე მოწყობილობაზე უნდა შეიყვანოს, სადაც მასზე დააწკაპუნა, და ტოკენი არ უნდა დარჩეს ლოგებში ან ანალიტიკის ინსტრუმენტებში.
• დაგჭირდებათ საიმედო ელფოსტის გაგზავნა — იხილეთ როგორ გავაგზავნოთ ელფოსტა აპიდან. შეამოწმეთ Gmail-სა და Outlook-ში და ნაგვის საქაღალდეში.

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“.
3. დაამატეთ authorized JavaScript origins და redirect URI-ები — ზუსტი მისამართები, სადაც თქვენი აპი მუშაობს და სადაც Google მომხმარებელს შესვლის შემდეგ უბრუნებს.
4. შეინახეთ კლიენტის ID და კლიენტის საიდუმლო აპის საიდუმლოებში.

Google-ის OAuth დოკუმენტაციის მიხედვით, ხშირად ხდება შემდეგი:

• redirect_uri_mismatch: მისამართი ზუსტად უნდა დაემთხვეს, მათ შორის http-ისა და https-ის, სიმბოლოების რეგისტრის და ბოლო „/“-ის მიმართ. დაამატეთ ერთი თქვენი გადახედვის მისამართისთვის და ერთი ცოცხალი დომენისთვის.
• საჭიროა HTTPS: redirect URI-ები უნდა იყენებდეს HTTPS-ს, გარდა localhost-ისა დეველოპმენტის დროს.
• state პარამეტრი უნდა შემოწმდეს დაბრუნებისას, რათა დაცული იყოს cross-site request forgery-სგან. კარგი ბიბლიოთეკები ამას თქვენთვის აკეთებენ.

თუ მხოლოდ ძირითად ინფორმაციას ითხოვთ (სახელი, ელფოსტა, პროფილი), Google ამბობს, რომ აპის გადამოწმება სავალდებულო არ არის. მომხმარებლების Gmail-ზე, Drive-ზე ან Calendar-ზე წვდომის თხოვნა განსხვავებულია და გადამოწმებას მოითხოვს.

თვითონ ააგოთ თუ პროვაიდერი გამოიყენოთ?

პირველი ორივე მიდგომა გონივრულია. ჰოსტირებული პროვაიდერები მეტს თავად აკეთებენ, მაგრამ დამოკიდებულებას ამატებენ და ზოგჯერ აქტიურ მომხმარებელზე იხდიან; ფასები მათ საიტებზე შეამოწმეთ. ბიბლიოთეკები ყველაფერს თქვენს მონაცემთა ბაზაში ინახავენ, მაგრამ მეტი რამ თქვენ უნდა სწორად დააკონფიგურიროთ. რომელიც არ უნდა აირჩიოთ, სთხოვეთ AI-ს, რომ იგი გამოიყენოს და არ დაწეროს პაროლის ან სესიის ლოგიკა ხელით.

როლები და უფლებები

შესვლა გეუბნებათ, ვინ არის ადამიანი. უფლებები წყვეტს, რა შეუძლია მას. დასაწყისისთვის მარტივად შეინახეთ:

წესები, რომლებიც როლების სახელებზე მეტს ნიშნავს:

• სერვერზე შეამოწმეთ ყოველ ჯერზე. ღილაკის დამალვა გვერდზე არ აჩერებს ვინმეს, რომელიც API-ს პირდაპირ იძახებს.
• მფლობელით შეზღუდეთ. წევრმა, რომელიც „დაჯავშნა 123“-ს ითხოვს, უნდა მიიღოს ის მხოლოდ მაშინ, თუ მისია.
• მომხმარებლებმა თავად ვერ აამაღლონ თავი. პროფილის განახლებისას უგულებელყავით ბრაუზერიდან გამოგზავნილი როლის ველები.
• ნაგულისხმევად წვდომის გარეშე. ახალი მარშრუტები მოითხოვდეს შესვლას, თუ თქვენ სხვაგვარად არ გადაწყვეტთ.

გამოცადეთ ორი ანგარიშით: შედით ერთით, ჩაიწერეთ ჩანაწერის ID, შემდეგ შედით მეორეთი და სცადეთ მისი გახსნა. სრული ტესტი მოცემულია უსაფრთხოების ჩამონათვალში.

სესიის უსაფრთხოება

შესვლის შემდეგ აპი მომხმარებელს სესიით იმახსოვრებს — ჩვეულებრივ ქუქი-ფაილით. OWASP-ის სესიების მართვის რეკომენდაციები:

• სესიის ქუქი-ფაილები დაყენებულია Secure (მხოლოდ HTTPS), HttpOnly (არ იკითხება გვერდის სკრიპტებით) და SameSite ატრიბუტებით
• შესვლისას გაიცემა ახალი სესიის ID, და ხელახლა — უფლებების შეცვლისას
• მოქმედებს უმოქმედობის დროის ლიმიტი და აბსოლუტური მაქსიმალური ხანგრძლივობა, სერვერზე აღსრულებული
• გამოსვლა სერვერზე ასრულებს სესიას და არა მხოლოდ ქუქის წაშლით
• პაროლის შეცვლისას სესიები ბათილდება

ბრაუზერის local storage-ში შესვლის ტოკენების შენახვა გავრცელებულია სახელმძღვანელოებში, მაგრამ ამით ისინი ნებისმიერ სკრიპტს ხელმისაწვდომს ხდის, რომელიც გვერდზე მუშაობს; უსაფრთხო ქუქი-ფაილები ჩვეულებრივ უკეთესი ნაგულისხმევია ვებ აპებისთვის.

პრომპტი, რომელიც ძირითადს მოიცავს

დაამატე მომხმარებლის ანგარიშები ამ აპს. მომხმარებლებს შეეძლებათ რეგისტრაცია და შესვლა ელფოსტითა და პაროლით, ან Google-ით. გამოიყენე [ბიბლიოთეკა ან პროვაიდერი] და არა საკუთარი ავთენტიფიკაციის კოდი. პაროლები დაჰეშე Argon2id-ით ან bcrypt-ით. დაამატე პაროლის აღდგენა ელფოსტით, ერთჯერადი ბმულით, რომელიც ერთ საათში ვადაგასულდება. სესიები შეინახე უსაფრთხო, HttpOnly ქუქი-ფაილებში. დაიცავი /dashboard და ყველა /api მარშრუტი, რომ მათი გამოყენება მხოლოდ შესულ მომხმარებლებს შეეძლოთ, და დარწმუნდი, რომ მომხმარებელს მხოლოდ საკუთარი პროექტების ნახვა შეუძლია. დაამატე „admin“ როლი, რომელსაც შეუძლია ყველა მომხმარებლის ნახვა; /admin-ზე მხოლოდ ადმინისტრატორებს შეუძლიათ შესვლა, რაც სერვერზე შემოწმდება.

შემდეგ შეამოწმეთ: დარეგისტრირდით, გამოხვიდით, შედით, აღადგინეთ პაროლი, სცადეთ კერძო URL გასვლის შემდეგ და სცადეთ სხვა მომხმარებლის ჩანაწერი.

ხშირი შეცდომები AI-ით აშენებულ შესვლაში

• დაცვა მხოლოდ გვერდზე. გვერდი გამოსულ მომხმარებლებს გადააბრუნებს, მაგრამ API მონაცემებს ნებისმიერს დაუბრუნებს.
• საიდუმლოები ბრაუზერში. OAuth კლიენტის საიდუმლოები და ავთენტიფიკაციის პროვაიდერის ადმინისტრატორის გასაღებები სერვერზე უნდა იყოს.
• გადახედვისა და ცოცხალი URL-ების აღრევა. Google-ის redirect URI ან აღდგენის ელფოსტის ბმული გადახედვაზე მიუთითებს, ამიტომ გამოქვეყნების შემდეგ შესვლა იშლება.
• ელფოსტის დადასტურების არქონა. ნებისმიერს შეუძლია დარეგისტრირდეს როგორც anyone@company.com. ამ მისამართთან დაკავშირებული რამის მინიჭებამდე დაადასტურეთ ელფოსტა.
• მხოლოდ წარმატებული სცენარის ტესტირება. სცადეთ არასწორი პაროლები, ვადაგასული ბმულები და მეორე ანგარიში.

შესვლის დამატება Mythex-ში

Mythex-ზე შესვლა თქვენი აპის მომხმარებლებისთვის არის რაღაც, რასაც აპში ამატებთ — ეს განცალკევებულია თქვენი საკუთარი Mythex ანგარიშისგან. Mythex არ გვთავაზობს ჩაშენებულ ავთენტიფიკაციის პროდუქტს, ამიტომ თქვენ მოგაქვთ ავთენტიფიკაციის ბიბლიოთეკა ან პროვაიდერი და მისი გასაღებები:

1. აირჩიეთ მიდგომა — მაგალითად, ელფოსტა და პაროლი თქვენს მონაცემთა ბაზაში, ან ჰოსტირებული პროვაიდერის SDK.
2. თუ მომხმარებლებს თავად ინახავთ, აპს მონაცემთა ბაზა დასჭირდება; მოითხოვეთ ჩატში ან გამოიყენეთ /database.
3. პროვაიდერის გასაღებები ჩადეთ პროექტის საიდუმლოებში (/secrets ან პროექტის პარამეტრები).
4. გამოიყენეთ ზემოთ მოცემული მსგავსი პრომპტი და შეამოწმეთ Preview-ში. Google-ით შესვლისთვის დაამატეთ redirect URI-ები თქვენი გადახედვისა და გამოქვეყნებული მისამართებისთვის.

იხილეთ დაამატე შესვლა შენს აპში დოკუმენტაციაში. თუ ფასიან პროდუქტს აშენებთ, როგორ ავაშენოთ SaaS MVP ანგარიშებსა და ანგარიშსწორებას ერთად განიხილავს.

კითხვები