Как да добавите вход в приложението си: пароли, магически линкове, Google и роли

За да добавите вход към приложението, изберете метод — имейл и парола, магически линкове (еднократен линк за вход, изпратен по имейл) или „Вход с Google“ — и го реализирайте с утвърдена библиотека за автентикация или хостнат доставчик, вместо от нулата. След това решете какво може да прави всеки тип потребител (роли) и налагайте това на сървъра за всяка страница и заявка към API. Сесиите трябва да използват сигурни бисквитки, да изтичат и да приключват правилно при изход.

Това ръководство разглежда всеки избор и детайлите, които отделят работещия вход от безопасния. За концепциите зад него вижте какво е автентикация.

Първо решете: изобщо нужен ли ви е вход?

Входът добавя триене и отговорност. Трябва ви, когато:

• Потребителите имат лични данни (свои резервации, документи, фактури)
• Потребителите могат да променят неща, които други ще виждат
• Таксувате достъп
• Различни хора имат различни права (собственик, персонал, клиент)

Вероятно не ви трябва за маркетингов сайт, публичен указател или формуляр, който просто ви изпраща имейл. Списъкът с чакащи не изисква акаунти; поле за имейл е достатъчно.

Четирите често срещани метода за вход

Много приложения комбинират два: Вход с Google плюс магически линкове по имейл е популярна двойка, която покрива повечето хора, без да се пазят пароли.

Имейл и парола

Ако предлагате пароли, тези неща са задължителни:

• Хеширайте паролите с бавен алгоритъм за хеширане на пароли. Насоките на OWASP за съхранение на пароли препоръчват Argon2id, като alternatives са scrypt, bcrypt или PBKDF2. Никога не пазете пароли като обикновен текст или с бърз общ хеш.
• Възстановяването на парола използва случаен, еднократен линк, който изтича, изпратен на проверения имейл.
• Не показвайте кои имейли имат акаунти. „Ако този имейл е регистриран, изпратихме линк за възстановяване“ е по-добре от „Не е намерен акаунт“.
• Ограничавайте честотата на опитите за вход и възстановяване, за да забавите подбора на пароли.
• Позволете дълги пароли и мениджъри на пароли; пропуснете правилата, които налагат странни комбинации от символи.

Магически линкове и еднократни кодове

Магическият линк е линк за вход, изпратен на потребителя по имейл. Като кликне, потребителят влиза. Еднократният код е същата идея, само че се въвежда вместо да се кликва.

• Линковете и кодовете изтичат бързо и работят само веднъж.
• Линкът трябва да влиза потребителя на устройството, където е кликнат, а токенът не бива да остава в логове или инструменти за аналитика.
• Нужно ви е надеждно изпращане на имейли — вижте как да изпращате имейли от приложението си. Тествайте с Gmail и Outlook и проверявайте папките за спам.

Вход с Google (и други OAuth доставчици)

„Вход с Google“ използва OAuth и OpenID Connect: Google потвърждава кой е потребителят и казва на приложението имейла и името му. Настройката към септември 2026 се прави в секцията Google Auth Platform на Google Cloud Console:

1. Създайте или изберете проект и попълнете страницата Branding — какво виждат потребителите на екрана за съгласие (име на приложението, имейл за поддръжка, лого).
2. На страницата Clients създайте клиент от тип „Web application“.
3. Добавете authorized JavaScript origins и redirect URIs — точните адреси, на които работи приложението ви и към които Google връща потребителите след вход.
4. Запазете client ID и client secret в тайните на приложението.

Нещата, които често се объркват, според документацията на 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 на сесия се издава при вход и отново, когато правата се променят
• Изтичане при бездействие и максимална абсолютна продължителност, налагани на сървъра
• Изходът прекратява сесията на сървъра, а не само изтрива бисквитката
• Сесиите се анулират, когато потребителят смени паролата си

Съхранението на токени за вход в localStorage на браузъра е често срещано в уроците, но ги излага на всеки скрипт, работещ на страницата; сигурните бисквитки обикновено са по-добрият избор за уеб приложения.

Промпт, който покрива основите

Добави потребителски акаунти към това приложение. Потребителите могат да се регистрират и влизат с имейл и парола или с Google. Използвай [библиотека или доставчик] вместо собствен код за автентикация. Хеширай паролите с Argon2id или bcrypt. Добави възстановяване на парола по имейл с еднократен линк, който изтича след един час. Пази сесиите в сигурни бисквитки с HttpOnly. Защитавай /dashboard и всеки маршрут /api, така че само влезлите потребители да ги ползват, и се увери, че потребителите виждат само своите проекти. Добави роля „admin“, която може да вижда всички потребители; само администраторите могат да достигнат /admin, проверено на сървъра.

После тествайте: регистрирайте се, излезте, влезте, възстановете парола, опитайте частен URL без вход и запис на друг потребител.

Чести грешки в създадения с AI вход

• Защита само в страницата. Страницата пренасочва непълномощните потребители, но API връща данни на всеки.
• Тайни в браузъра. Тайните на OAuth клиентите и административните ключове на доставчика на автентикация принадлежат на сървъра.
• Смесени преглед и жив URL. Redirect URI на Google или линкът за възстановяване в имейла сочат към прегледа, така че входът се чупи след публикуване.
• Без проверка на имейл. Всеки може да се регистрира като anyone@company.com. Проверявайте имейла, преди да давате нещо, свързано с този адрес.
• Тестване само на правилния път. Опитайте грешни пароли, изтекли линкове и втори акаунт.

Добавяне на вход в Mythex

В Mythex входът за потребителите на вашето приложение е нещо, което добавяте към приложението си — той е отделен от собствения ви акаунт в Mythex. Mythex не предоставя вграден продукт за автентикация, затова донасяте библиотека или доставчик за автентикация и техните ключове:

1. Изберете подход — например имейл и парола, съхранявани в собствената ви база данни, или SDK на хостнат доставчик.
2. Ако съхранявате потребителите сами, приложението се нуждае от база данни; поискайте я в чата или използвайте /database.
3. Пазете ключовете на доставчика в тайни на проекта (/secrets или настройките на проекта).
4. Използвайте промпт като горния и тествайте в Preview. За Вход с Google добавете redirect URI както за прегледа, така и за публикувания адрес.

Вижте Добавяне на вход в приложението в документацията. Ако строите платен продукт, как да създадете SaaS MVP обхваща акаунти и плащания заедно.

Въпроси