Cara Menambah Log Masuk ke Apl Anda: Kata Laluan, Pautan Ajaib, Google dan Peranan

Untuk menambah log masuk ke apl, pilih satu kaedah — e-mel dan kata laluan, pautan ajaib (pautan log masuk sekali guna yang dihantar melalui e-mel), atau “Log masuk dengan Google” — dan laksanakannya dengan perpustakaan auth yang telah terbukti atau penyedia yang dihoskan, bukan dari sifar. Kemudian tentukan apa yang boleh dilakukan oleh setiap jenis pengguna (peranan), dan kuatkuasakannya di pelayan untuk setiap halaman dan permintaan API. Sesi hendaklah menggunakan kuki selamat, tamat tempoh, dan tamat dengan betul apabila log keluar.

Panduan ini membincangkan setiap pilihan dan butiran yang membezakan log masuk yang berfungsi daripada log masuk yang selamat. Untuk konsep di sebalik semua ini, lihat apa itu pengesahan.

Tentukan dahulu: adakah anda memerlukan log masuk?

Log masuk menambah geseran dan tanggungjawab. Anda memerlukannya apabila:

• Pengguna mempunyai data peribadi (tempahan, dokumen, invois mereka)
• Pengguna boleh menukar perkara yang akan dilihat oleh orang lain
• Anda mengenakan bayaran untuk akses
• Orang yang berbeza memerlukan kebenaran yang berbeza (pemilik berbanding kakitangan berbanding pelanggan)

Anda mungkin tidak memerlukannya untuk laman pemasaran, direktori awam, atau borang yang hanya menghantar e-mel kepada anda. Senarai tunggu tidak memerlukan akaun; medan e-mel sudah memadai.

Empat kaedah log masuk yang biasa

Banyak apl menggabungkan dua: log masuk Google ditambah pautan ajaib e-mel ialah gandingan popular yang meliputi kebanyakan orang tanpa menyimpan sebarang kata laluan.

E-mel dan kata laluan

Jika anda menawarkan kata laluan, ini perkara yang tidak boleh dikompromi:

• Cincang kata laluan dengan algoritma cincang kata laluan yang perlahan. Panduan penyimpanan kata laluan OWASP mengesyorkan Argon2id, dengan scrypt, bcrypt atau PBKDF2 sebagai alternatif. Jangan sekali-kali menyimpan kata laluan dalam teks biasa atau dengan cincang umum yang pantas.
• Tetapan semula kata laluan menggunakan pautan rawak, sekali guna, yang tamat tempoh, dihantar ke e-mel yang telah disahkan.
• Jangan dedahkan e-mel mana yang mempunyai akaun. “Jika e-mel itu didaftarkan, kami telah menghantar pautan tetapan semula” lebih baik daripada “Akaun tidak dijumpai”.
• Hadkan kadar percubaan log masuk dan tetapan semula untuk memperlahankan tekaan kata laluan.
• Benarkan kata laluan yang panjang dan pengurus kata laluan; elakkan peraturan yang memaksa gabungan aksara yang pelik.

Pautan ajaib dan kod sekali guna

Pautan ajaib ialah pautan log masuk yang dihantar kepada pengguna melalui e-mel. Mengkliknya akan log masuk pengguna. Kod sekali guna ialah idea yang sama, tetapi ditaip dan bukannya diklik.

• Pautan dan kod tamat tempoh dengan cepat dan hanya berfungsi sekali.
• Pautan patut log masuk pengguna pada peranti tempat ia diklik, dan token tidak boleh kekal dalam log atau alat analitik.
• Anda memerlukan penghantaran e-mel yang boleh dipercayai — lihat cara menghantar e-mel dari apl anda. Uji dengan Gmail dan Outlook, dan semak folder spam.

Log masuk dengan Google (dan penyedia OAuth lain)

“Log masuk dengan Google” menggunakan OAuth dan OpenID Connect: Google mengesahkan siapa pengguna itu dan memberitahu apl anda e-mel dan nama mereka. Persediaan, setakat September 2026, berlaku dalam bahagian Google Auth Platform di Google Cloud Console:

1. Cipta atau pilih projek, dan isi halaman Branding — apa yang dilihat pengguna pada skrin persetujuan (nama apl, e-mel sokongan, logo).
2. Pada halaman Clients, cipta klien jenis “Web application”.
3. Tambah authorized JavaScript origins dan redirect URIs anda — alamat tepat tempat apl anda berjalan dan tempat Google menghantar pengguna kembali selepas log masuk.
4. Simpan ID klien dan rahsia klien dalam rahsia apl anda.

Perkara yang biasanya tersilap, mengikut dokumentasi OAuth Google:

• redirect_uri_mismatch: alamat pengalihan mesti sepadan tepat, termasuk http berbanding https, huruf besar kecil dan sebarang garis miring di hujung. Tambah satu untuk alamat pratonton anda dan satu untuk domain langsung anda.
• HTTPS diperlukan: URI pengalihan mesti menggunakan HTTPS, kecuali localhost semasa pembangunan.
• Parameter state patut disemak apabila kembali bagi melindungi daripada pemalsuan permintaan rentas tapak (CSRF). Perpustakaan yang baik melakukannya untuk anda.

Jika anda hanya meminta maklumat log masuk asas (nama, e-mel, profil), Google menyatakan pengesahan aplikasi tidak wajib. Meminta akses kepada Gmail, Drive atau Kalendar pengguna adalah berbeza dan memerlukan pengesahan.

Bina sendiri atau gunakan penyedia?

Kedua-dua yang pertama adalah munasabah. Penyedia yang dihoskan mengendalikan lebih banyak perkara untuk anda tetapi menambah kebergantungan dan kadangkala kos bagi setiap pengguna aktif; semak harga semasa di laman mereka. Perpustakaan menyimpan semuanya dalam pangkalan data anda tetapi meninggalkan lebih banyak perkara untuk anda konfigurasi dengan betul. Apa pun pilihan anda, minta AI menggunakannya dan bukannya menulis logik kata laluan atau sesi sendiri.

Peranan dan kebenaran

Log masuk memberitahu anda siapa seseorang itu. Kebenaran memutuskan apa yang mereka boleh lakukan. Kekalkan ia ringkas pada mulanya:

Peraturan yang lebih penting daripada nama peranan:

• Semak di pelayan, setiap kali. Menyembunyikan butang dalam halaman tidak menghentikan sesiapa memanggil API secara terus.
• Skop mengikut pemilik. Ahli yang mengambil “tempahan 123” hanya patut mendapatkannya jika ia miliknya.
• Pengguna tidak boleh menaikkan peranan sendiri. Abaikan medan peranan yang dihantar dari pelayar semasa kemas kini profil.
• Lalai kepada tiada akses. Laluan baharu patut memerlukan log masuk melainkan anda memutuskan sebaliknya.

Uji dengan dua akaun: log masuk sebagai satu, catat ID rekod, kemudian log masuk sebagai yang lain dan cuba membukanya. Senarai semak keselamatan kami mempunyai ujian penuh.

Keselamatan sesi

Selepas log masuk, apl mengingati pengguna dengan sesi — biasanya kuki. Panduan pengurusan sesi OWASP mengesyorkan:

• Kuki sesi ditetapkan dengan Secure (HTTPS sahaja), HttpOnly (tidak boleh dibaca oleh skrip halaman) dan SameSite
• ID sesi baharu dikeluarkan semasa log masuk, dan sekali lagi apabila keistimewaan berubah
• Tamat tempoh tidak aktif dan jangka hayat maksimum mutlak, dikuatkuasakan di pelayan
• Log keluar yang menamatkan sesi di pelayan, bukan sekadar memadam kuki
• Sesi dibatalkan apabila pengguna menukar kata laluan mereka

Menyimpan token log masuk dalam storan tempatan pelayar adalah biasa dalam tutorial tetapi mendedahkannya kepada mana-mana skrip yang berjalan pada halaman; kuki selamat biasanya pilihan lalai yang lebih baik untuk apl web.

Satu prompt yang merangkumi perkara asas

Tambahkan akaun pengguna kepada apl ini. Pengguna boleh mendaftar dan log masuk dengan e-mel dan kata laluan, atau dengan Google. Gunakan [perpustakaan atau penyedia] dan bukannya kod auth tersuai. Cincang kata laluan dengan Argon2id atau bcrypt. Tambah tetapan semula kata laluan melalui e-mel dengan pautan sekali guna yang tamat tempoh dalam satu jam. Simpan sesi dalam kuki selamat dan HttpOnly. Lindungi /dashboard dan setiap laluan /api supaya hanya pengguna yang log masuk boleh menggunakannya, dan pastikan pengguna hanya boleh melihat projek mereka sendiri. Tambah peranan “admin” yang boleh melihat semua pengguna; hanya admin boleh mencapai /admin, disemak di pelayan.

Kemudian uji: daftar, log keluar, log masuk, tetapkan semula kata laluan, cuba URL persendirian semasa tidak log masuk, dan cuba rekod pengguna lain.

Kesilapan biasa dalam log masuk yang dibina dengan AI

• Perlindungan hanya dalam halaman. Halaman mengalihkan pengguna yang tidak log masuk, tetapi API memulangkan data kepada sesiapa sahaja.
• Rahsia dalam pelayar. Rahsia klien OAuth dan kunci pentadbir penyedia auth mesti berada di pelayan.
• URL pratonton dan langsung bercampur. Pengalihan semula Google atau pautan tetapan semula e-mel menunjuk ke pratonton, jadi log masuk rosak selepas diterbitkan.
• Tiada pengesahan e-mel. Sesiapa sahaja boleh mendaftar sebagai anyone@company.com. Sahkan e-mel sebelum memberikan apa-apa yang dikaitkan dengan alamat itu.
• Hanya menguji laluan ideal. Cuba kata laluan yang salah, pautan yang tamat tempoh dan akaun kedua.

Menambah log masuk dalam Mythex

Di Mythex, log masuk untuk pengguna apl anda ialah sesuatu yang anda tambah ke apl anda — ia berasingan daripada akaun Mythex anda sendiri. Mythex tidak menyediakan produk auth terbina dalam, jadi anda membawa perpustakaan auth atau penyedia dan kuncinya sendiri:

1. Pilih pendekatan — contohnya e-mel dan kata laluan yang disimpan dalam pangkalan data anda sendiri, atau SDK penyedia yang dihoskan.
2. Jika anda menyimpan pengguna sendiri, apl memerlukan pangkalan data; minta dalam sembang atau gunakan /database.
3. Letakkan kunci penyedia dalam rahsia projek (/secrets atau tetapan projek).
4. Gunakan prompt seperti di atas, kemudian uji dalam Pratonton. Untuk log masuk Google, tambah URI pengalihan untuk kedua-dua alamat pratonton dan alamat yang diterbitkan anda.

Lihat Tambah log masuk ke apl anda dalam dokumentasi. Jika anda membina produk berbayar, cara membina MVP SaaS merangkumi akaun dan pengebilan bersama.

Soalan lazim