Како да додадете најава во вашата апликација: лозинки, магични линкови, Google и улоги

За да додадете најава во апликација, изберете метод — е-пошта и лозинка, магични линкови (еднократен линк за најава испратен по е-пошта) или „Најава со Google“ — и имплементирајте го со докажана библиотека за автентикација или хостиран давател, наместо од почеток. Потоа одлучете што смее да прави секој тип на корисник (улоги), и спроведете го тоа на серверот за секоја страница и секое API барање. Сесиите треба да користат безбедни колачиња, да истекуваат и правилно да завршуваат при одјава.

Овој водич ги поминува секој избор и деталите што ја разликуваат работната најава од безбедната. За концептите зад неа, видете што е автентикација.

Прво одлучете: дали воопшто ви треба најава?

Најавата додава трење и одговорност. Ви треба кога:

• Корисниците имаат приватни податоци (нивните резервации, документи, фактури)
• Корисниците можат да менуваат нешто што другите ќе го видат
• Наплаќате пристап
• Различни луѓе треба различни дозволи (сопственик наспроти персонал наспроти клиент)

Можеби не ви треба за маркетиншки сајт, јавен именик или образец што само ви испраќа е-пошта. Листа за чекање не бара сметки; доволно е поле за е-пошта.

Четирите вообичаени методи за најава

Многу апликации комбинираат два: Најава со Google плус магични линкови по е-пошта е популарен пар што ги покрива повеќето луѓе без чување лозинки.

Е-пошта и лозинка

Ако нудите лозинки, ова се необично важни работи:

• Хеширајте ги лозинките со бавен алгоритам за хеширање на лозинки. Упатството на OWASP за чување лозинки препорачува Argon2id, со scrypt, bcrypt или PBKDF2 како алтернативи. Никогаш не чувајте лозинки во чист текст или со брз општ hash.
• Ресетирањата на лозинки користат случаен, еднократен линк што истекува, испратен на верифицирана е-пошта.
• Не откривајте кои е-пошти имаат сметки. „Ако таа е-пошта е регистрирана, испративме линк за ресетирање“ е подобро од „Нема пронајдена сметка“.
• Ограничете ја брзината на обидите за најава и ресетирање за да се успори погодувањето на лозинки.
• Дозволете долги лозинки и менаџери на лозинки; не користете правила што бараат чудна комбинација на знаци.

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

Магичен линк е линк за најава испратен по е-пошта на корисникот. Со кликнување, корисникот се најавува. Еднократен код е истата идеја, но се внесува наместо да се кликне.

• Линковите и кодовите брзо истекуваат и работат само еднаш.
• Линкот треба да ја најави корисникот на уредот каде кликнал, а токенот не смее да остане во логовите или алатките за аналитика.
• Ви треба сигурна испорака на е-пошта — видете како да испраќате е-пошта од вашата апликација. Тестирајте со 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. Чувајте го ID-то на клиентот и тајната на клиентот во тајните на апликацијата.

Нештата што обично не функционираат, според документацијата за OAuth на Google:

• redirect_uri_mismatch: адресата за пренасочување мора точно да се совпаѓа, вклучувајќи http наспроти https, големи и мали букви и завршна коса црта. Додајте по една за адресата на прегледот и една за вашиот живи домен.
• Потребен HTTPS: URI-јата за пренасочување мора да користат HTTPS, освен localhost при развој.
• Параметарот state треба да се проверува при враќањето, за да се заштити од cross-site request forgery. Добрите библиотеки ова го прават за вас.

Ако барате само основни информации за најава (име, е-пошта, профил), Google вели дека верификација на апликацијата не е задолжителна. Барањето пристап до Gmail, Drive или Calendar на корисниците е поинаку и бара верификација.

Градите сами или користите давател?

Овие први два се разумни. Хостираните даватели повеќе работи ги решаваат за вас, но додаваат зависност и понекогаш чинат по активен корисник; проверете ги актуелните цени на нивните страници. Библиотеките ги држат сите податоци во вашата база, но остануваат повеќе работи за правилно конфигурирање. Што и да изберете, побарајте од AI да користи готова логика, наместо да пишува сопствена за лозинки или сесии.

Улоги и дозволи

Најавата ви кажува кој е некој. Дозволите одлучуваат што смее да прави. Почнете едноставно:

Правилата што повеќе важат од имињата на улогите:

• Проверете на серверот, секогаш. Скривањето копче на страницата не го спречува никој да го повика API-то директно.
• Ограничувајте по сопственик. Член што бара „резервација 123“ смее да ја добие само ако е негова.
• Корисниците не можат сами да се унапредат. Игнорирајте полиња за улоги испратени од прелистувачот при ажурирање на профилот.
• Стандардно без пристап. Новите рути треба да бараат најава, освен ако не одлучите поинаку.

Тестирајте со две сметки: најавете се со едната, забележете ID на запис, најавете се со другата и обидете се да го отворите. Нашата безбедносна листа за апликации направени со AI го содржи целосниот тест.

Безбедност на сесијата

По најавата, апликацијата го памети корисникот со сесија — обично колаче. Упатството на OWASP за управување со сесии препорачува:

• Колачињата за сесија се поставени со Secure (само преку HTTPS), HttpOnly (нечитливи за скриптите на страницата) и SameSite
• Нов ID на сесија се издава при најава, и повторно кога ќе се променат привилегиите
• Истек при неактивност и максимален абсолутен животен век, спроведени на серверот
• Одјавата ја завршува сесијата на серверот, а не само брише колаче
• Сесиите се поништуваат кога корисникот ќе ја промени лозинката

Чувањето токени за најава во локалното складирање на прелистувачот е вообичаено во туторијали, но ги изложува на секоја скрипта што работи на страницата; безбедните колачиња обично се подобар стандард за веб-апликации.

Промпт што ги покрива основните работи

Додај кориснички сметки во оваа апликација. Корисниците може да се регистрираат и да се најавуваат со е-пошта и лозинка или со Google. Користи [библиотека или давател] наместо сопствен код за автентикација. Хеширај ги лозинките со Argon2id или bcrypt. Додај ресетирање на лозинка по е-пошта со еднократен линк што истекува за еден час. Чувај ги сесиите во безбедни HttpOnly колачиња. Заштитете /dashboard и секоја /api рута така што само најавените корисници ќе може да ги користат, и осигурајте се дека корисниците можат да ги видат само своите проекти. Додај улога „admin“ што може да ги види сите корисници; само администраторите смеат да пристапат до /admin, проверено на серверот.

Потоа тестирајте: регистрирајте се, одјавете се, најавете се, ресетирајте ја лозинката, обидете се да отворите приватен URL кога сте одјавени и обидете се да отворите запис на друг корисник.

Чести грешки во најава направена со AI

• Заштита само во страницата. Страницата ги пренасочува одјавените корисници, но API-то враќа податоци на секој.
• Тајни во прелистувачот. Тајните на OAuth клиентот и административните клучеви на давателот на автентикација припаѓаат на серверот.
• Преглед и живи URL-адреси се помешани. URI-то за пренасочување на Google или линкот за ресетирање во е-пошта покажува кон прегледот, па најавата се расипува по објавување.
• Нема верификација на е-пошта. Секој може да се регистрира како anyone@company.com. Верификувајте е-пошта пред да доделите што било што поврзано за таа адреса.
• Тестирање само на успешниот пат. Обидете се со погрешни лозинки, истечени линкови и втора сметка.

Додавање најава во Mythex

Во Mythex, најавата за корисниците на вашата апликација ја додавате во вашата апликација — таа е одвоена од вашата сопствена сметка на Mythex. Mythex не нуди вграден производ за автентикација, па донесувате библиотека или давател за автентикација и нивните клучеви:

1. Изберете пристап — на пример е-пошта и лозинка зачувани во вашата сопствена база или SDK на хостиран давател.
2. Ако корисниците ги чувате сами, апликацијата ви треба база на податоци; побарајте ја во разговорот или користете /database.
3. Ставете ги клучевите на давателот во тајни на проектот (/secrets или поставките на проектот).
4. Користете промпт како горниот, па тестирајте во Preview. За најава со Google, додајте URI-ја за пренасочување и за адресата на прегледот и за објавената адреса.

Видете Додај најава во вашата апликација во документацијата. Ако градите платен производ, како да изградите SaaS MVP ги опфаќа сметките и наплатата заедно.

Прашања