Paano Magdagdag ng Login sa App Mo: Passwords, Magic Links, Google at Roles

Para magdagdag ng login sa app, pumili ng paraan: email at password, magic links (isang beses na sign-in link na ipinapadala sa email), o "Sign in with Google". Ipatupad ito gamit ang napatunayang auth library o hosted provider sa halip na isulat mula sa simula. Pagkatapos, magpasya kung ano ang puwedeng gawin ng bawat uri ng user (roles), at ipatupad ito sa server para sa bawat page at API request. Dapat gumamit ng secure cookies ang sessions, mag-expire, at maayos na magtapos sa logout.

Sinusuri ng gabay na ito ang bawat pagpipilian at ang mga detalyeng nagpapaiba sa gumaganang login at sa ligtas na login. Para sa mga konseptong nasa likod nito, tingnan ang ano ang authentication.

Unang tanong: kailangan mo ba talaga ng login?

Nagdadala ng abala at responsibilidad ang login. Kailangan mo ito kapag:

• May pribadong data ang users (kanilang bookings, dokumento, invoices)
• Puwedeng baguhin ng users ang mga bagay na makikita ng iba
• Naniningil ka para sa access
• Magkakaiba ang permiso ng mga tao (owner vs staff vs customer)

Maaaring hindi mo ito kailangan para sa marketing site, pampublikong directory, o form na nagpapadala lang ng email sa iyo. Hindi kailangan ng accounts ang waitlist; sapat na ang email field.

Ang apat na karaniwang paraan ng login

Marami ang pinagsasama ang dalawa: karaniwang pares ang Google sign-in at email magic links na sumasaklaw sa karamihan ng tao nang hindi nag-iimbak ng anumang password.

Email at password

Kung mag-aalok ka ng passwords, ito ang mga hindi puwedeng kulang:

• I-hash ang passwords gamit ang mabagal na password-hashing algorithm. Inirerekomenda ng gabay ng OWASP sa pag-iimbak ng password ang Argon2id, kasama ang scrypt, bcrypt o PBKDF2 bilang alternatibo. Huwag kailanman mag-imbak ng password nang plain text o gamit ang mabilis na general hash.
• Ang pag-reset ng password ay gumagamit ng random, isang beses lang magagamit at nag-e-expire na link, na ipinapadala sa na-verify na email.
• Huwag ipakita kung aling emails ang may account. Mas mabuti ang "Kung nakarehistro ang email na iyon, nagpadala na kami ng reset link" kaysa "Walang nakitang account".
• Limitahan ang rate ng login at reset attempts para bumagal ang paghula ng password.
• Payagan ang mahahabang password at password managers; alisin ang mga patakarang nagpipilit ng kakaibang halo ng character.

Magic links at one-time codes

Ang magic link ay sign-in link na ipinapadala sa email ng user. Kapag ki-na-click ito, naka-log in na ang user. Ang one-time code ay kaparehong ideya, pero ita-type sa halip na i-click.

• Mabilis mag-expire ang mga link at code at isang beses lang gumagana.
• Dapat mag-log in ng link ang user sa device kung saan ito na-click, at hindi dapat manatili ang token sa logs o analytics tools.
• Kailangan mo ng maaasahang pagpapadala ng email; tingnan ang paano magpadala ng email mula sa app mo. Subukan sa Gmail at Outlook, at tingnan ang spam folder.

Sign in with Google (at iba pang OAuth providers)

Gumagamit ang "Sign in with Google" ng OAuth at OpenID Connect: kinukumpirma ng Google kung sino ang user at sinasabi sa app mo ang email at pangalan nito. Ang setup, noong Setyembre 2026, ay nasa seksyong Google Auth Platform ng Google Cloud Console:

1. Gumawa o pumili ng project, at punan ang Branding page: ang makikita ng users sa consent screen (pangalan ng app, support email, logo).
2. Sa Clients page, gumawa ng client na uri ay "Web application".
3. Idagdag ang authorized JavaScript origins at redirect URIs: ang eksaktong address kung saan tumatakbo ang app mo at kung saan ibabalik ng Google ang users pagkatapos mag-sign in.
4. Itago ang client ID at client secret sa mga secret ng app mo.

Mga bagay na karaniwang nagkakamali, ayon sa dokumentasyon ng OAuth ng Google:

• redirect_uri_mismatch: dapat eksaktong magkatugma ang redirect address, kasama ang http vs https, malaki at maliit na titik, at anumang trailing slash. Magdagdag ng isa para sa preview address mo at isa para sa live domain mo.
• Kailangan ng HTTPS: dapat gumamit ng HTTPS ang redirect URIs, maliban sa localhost habang nagde-develop.
• Dapat suriin ang state parameter pagbalik para maprotektahan laban sa cross-site request forgery. Ginagawa ito para sa iyo ng mahuhusay na library.

Kung pangunahing impormasyon lang sa pag-sign in (pangalan, email, profile) ang hinihingi mo, sinasabi ng Google na hindi kailangan ang app verification. Iba ang paghingi ng access sa Gmail, Drive o Calendar ng users; kailangan iyon ng verification.

Gumawa ba ng sarili o gumamit ng provider?

Parehong makatwiran ang unang dalawa. Mas maraming hinahawakan para sa iyo ang hosted providers, pero nagdadagdag ng dependency at minsan may singil kada aktibong user; tingnan ang kasalukuyang presyo sa kanilang site. Pinapanatili ng libraries ang lahat sa sarili mong database, pero mas maraming kailangan mong i-configure nang tama. Alinman ang piliin mo, hilingin sa AI na gamitin ito sa halip na gumawa ng sariling logic para sa password o session.

Roles at permissions

Sinasabi ng login kung sino ang isang tao. Nagpapasya ang permissions kung ano ang puwede niyang gawin. Panatilihin muna itong simple:

Mga patakarang mas mahalaga kaysa sa pangalan ng role:

• Suriin sa server, sa bawat pagkakataon. Ang pagtatago ng button sa page ay hindi pumipigil sa sinumang tumawag nang direkta sa API.
• I-scope ayon sa may-ari. Ang member na kumukuha ng "booking 123" ay dapat lang makakuha nito kung kanya ito.
• Hindi puwedeng itaas ng users ang sarili nila. Huwag pansinin ang role fields na ipinapadala ng browser sa profile updates.
• Walang access bilang default. Ang mga bagong route ay dapat nangangailangan ng login maliban kung magpasya kang iba.

Subukan gamit ang dalawang account: mag-log in sa isa, itala ang ID ng isang record, mag-log in sa isa pa at subukang buksan ito. Kumpleto ang pagsubok na ito sa aming security checklist.

Seguridad ng session

Pagkatapos mag-log in, naaalala ng app ang user gamit ang session, karaniwang cookie. Inirerekomenda ng gabay ng OWASP sa session management ang mga sumusunod:

• Naka-set ang session cookies na may Secure (HTTPS lang), HttpOnly (hindi mababasa ng page scripts) at SameSite
• Bagong session ID ang ibinibigay sa pag-login, at muli kapag nagbago ang mga pribilehiyo
• May idle timeout at maximum na haba ng buhay, na ipinatutupad sa server
• Ang logout ay nagtatapos ng session sa server, hindi lang nagbubura ng cookie
• Ina-invalidate ang sessions kapag binago ng user ang password niya

Karaniwan sa mga tutorial ang pag-iimbak ng login tokens sa local storage ng browser, pero inilalantad nito ang mga ito sa anumang script na tumatakbo sa page; kadalasang mas mabuting default para sa web apps ang secure cookies.

Isang prompt na sumasaklaw sa mahahalagang bagay

Magdagdag ng user accounts sa app na ito. Puwedeng mag-sign up at mag-log in ang users gamit ang email at password, o gamit ang Google. Gumamit ng [library o provider] sa halip na custom auth code. I-hash ang passwords gamit ang Argon2id o bcrypt. Magdagdag ng password reset sa pamamagitan ng email na may single-use na link na mag-e-expire sa loob ng isang oras. Itago ang sessions sa secure at HttpOnly cookies. Protektahan ang /dashboard at bawat /api route para mga naka-log in lang na user ang makagamit nito, at siguraduhing makikita lang ng users ang sarili nilang projects. Magdagdag ng "admin" role na makakakita ng lahat ng users; ang mga admin lang ang makakarating sa /admin, na sinusuri sa server.

Pagkatapos, subukan: mag-sign up, mag-log out, mag-log in, mag-reset ng password, subukan ang private URL habang naka-log out, at subukan ang record ng ibang user.

Mga karaniwang pagkakamali sa login na gawa ng AI

• Proteksyon sa page lang. Nire-redirect ng page ang mga naka-log out na user, pero nagbabalik pa rin ng data ang API sa sinuman.
• Mga secret sa browser. Ang OAuth client secrets at admin keys ng auth provider ay dapat nasa server.
• Pinaghalo ang preview at live URLs. Ang redirect URI ng Google o ang link sa reset email ay nakaturo sa preview, kaya nasisira ang login pagkatapos mag-publish.
• Walang email verification. Sinuman ay puwedeng mag-sign up bilang anuman@kumpanya.com. I-verify muna ang email bago magbigay ng anumang nakatali sa address na iyon.
• Pagsubok lang sa maayos na landas. Subukan ang maling password, expired na links at pangalawang account.

Pagdaragdag ng login sa Mythex

Sa Mythex, ang login para sa mga user ng app mo ay idinadagdag mo sa app mo; hiwalay ito sa sarili mong Mythex account. Walang built-in na auth product ang Mythex, kaya magdadala ka ng auth library o provider at ng mga key nito:

1. Pumili ng paraan, halimbawa email at password na nakaimbak sa sarili mong database, o SDK ng hosted provider.
2. Kung ikaw mismo ang mag-iimbak ng users, kailangan ng app ng database; hingin ito sa chat o gamitin ang /database.
3. Ilagay ang provider keys sa project secrets (/secrets o project settings).
4. Gamitin ang prompt na tulad ng nasa itaas, pagkatapos subukan sa Preview. Para sa Google sign-in, magdagdag ng redirect URIs para sa preview at sa na-publish mong address.

Tingnan ang Add login to your app sa docs. Kung gumagawa ka ng bayad na produkto, sakop ng paano gumawa ng SaaS MVP ang accounts at billing nang magkasama.

Mga tanong