Mengapa menjadikan halaman login ke aplikasi satu halaman sebagai halaman terpisah?

28

Saya bertanya-tanya mengapa tampaknya menjadi populer untuk memiliki halaman login SPA menjadi halaman terpisah yang bukan halaman SPA (seperti dalam memuat dan mengirim data melalui permintaan ajax)?

Saya hanya memikirkan keamanan tetapi saya tidak dapat memikirkan alasan keamanan tertentu. Maksud saya satu-satunya hal yang terlintas dalam pikiran adalah bahwa jika halaman login Anda di bagian SPA, itu mengirimkan nama pengguna / kata sandi melalui ajax yang dapat dilihat oleh alat-alat seperti firebug atau web inspektur namun meskipun Anda mengirimnya seperti biasa Permintaan POST, ada alat lain yang dapat dengan mudah menangkap data ini (seperti biola, httpscoop, dll ...).

Apakah ada sesuatu yang saya lewatkan?

javascript architecture

— ryanzec
sumber

2

Saya tidak berpikir ada atau perlu menjadi alasan dalam kasus ini. Saya berpendapat, mengapa tidak?

— Steven Evers

1

Argumen saya menentangnya adalah bahwa memiliki halaman login sebagai halaman html terpisah sementara sisa aplikasi adalah arsitektur SPA tampak aneh tanpa manfaat nyata (meskipun titik yang dibuat msanford memang memiliki kelebihan).

— ryanzec

@ryanzec Terima kasih. Saya menambahkan contoh dalam upaya untuk menggambarkan bahwa ada manfaat nyata. Pertama, penghematan penundaan pemuatan aset di tempat lain tidak dapat diabaikan, terutama dalam kasus gagal masuk (atau penangguhan akun, dll.). Kedua, ini jauh lebih cepat untuk diimplementasikan daripada sistem modul berbasis ketergantungan asinkron yang lebih canggih, dan siklus hidup pengembangan merupakan pertimbangan penting (lihat mantra kantor * Opbeat (mengandung vulgar)).

— msanford

"Bahkan jika Anda mengirimnya sebagai permintaan POST normal, ada alat lain yang dapat dengan mudah menangkap data ini". Tentunya formulir login Anda dilindungi oleh HTTPS ?

— ajlane

@ajlane ya, login saya (dan sebenarnya, seluruh aplikasi) akan berjalan di belakang HTTPS

— ryanzec

18

Mungkin ini untuk menghemat pemuatan sekelompok aset sisi klien (seperti kerangka kerja JavaScript yang berat, gambar, dll ) yang hanya diperlukan oleh aplikasi.

Ada cara yang lebih canggih untuk mencapai tujuan kinerja yang serupa (lihat " Malte Ubl & John Hjelmstad: Sebuah novel, pendekatan efisien untuk pemuatan JavaScript - JSConf EU 2012 ") tetapi ini cukup cepat untuk diterapkan dan bisa dibilang sama efisiennya, terutama jika Aplikasi web Anda menggunakan hampir semua aset Anda.

Anda dapat melihat ini di alam bebas di situs seperti http://infogr.am beta:

http://infogr.am/login/ memuatfile jquery , raphael , custom js, dan 3 css.
http://infogr.am/beta/ (halaman SPI utama untuk aplikasi) memuat 10 kerangka kerja javascript, 5 file css eksternal, dan sekitar 60 gambar.

— msanford
sumber

Pembaruan: Pada 2016 dengan front-end angular2 dan back-end JBoss, kami masih melakukan ini untuk alasan yang sama.

— msanford

18

Saya pikir ada beberapa argumen yang masuk akal untuk atau menentang, dan saya akan mengatakan teknologi juga berperan dalam keputusan tersebut.

Orang bisa berargumentasi memiliki "halaman" login yang terpisah memungkinkan penggunaan "Keamanan Direktori". Umumnya siapa saja dapat melihat "halaman" login, tetapi hanya pengguna yang diautentikasi yang dapat melihat aplikasi "halaman" dan itu adalah "direktori". Rute juga dapat dikunci, di mana / Akun / berbeda dari / App / dan masing-masing memiliki "profil" keamanan sendiri.

Juga, jika Anda menggunakan pendekatan SPA dan Anda sedang menggabungkan otentikasi dengan pengalaman aplikasi, logika bisa berbelit-belit. Alih-alih menganggap pengguna "masuk karena mereka ada di sini", Anda harus terus-menerus memeriksa status otentikasi mereka dan bertanya "apakah pengguna ini ada di sini".

Juga, halaman login umumnya di situs yang menghadap konsumen .. Anda pergi ke www.yourapp.com dan memiliki beberapa info, kontak, dukungan, dll. Dan halaman "login" .. dari halaman login, setelah otentikasi, Anda dapat mengarahkan ulang ke seluruh host target ..

Alasan saya menyimpan halaman login yang terpisah, dan mengapa saya benar-benar memiliki aplikasi yang sama sekali berbeda untuk situs "yang menghadap konsumen" adalah karena saya dapat mengekspos sangat sedikit ke yang tidak diautentikasi. Kebetulan beberapa orang bodoh mulai menggedor halaman login saya, saya tidak ingin itu mempengaruhi sisi aplikasi hal-hal .. bahkan jika login hanya melakukan pencarian auth sederhana .. itu semacam membantu saya menjaga bozo dari mempengaruhi saya pengalaman pengguna .. Kasus terburuk, situs konsumen saya turun dan tidak ada yang bisa masuk, tapi setidaknya pengguna yang masuk tidak akan tahu dan pengalaman mereka tidak akan mulai melambat .. Saya tidak mengatakan itu adalah pilihan bukti peluru .. tapi setidaknya Saya telah mengisolasi risiko ke area yang tidak terauthentikasi ..

— Hanzolo
sumber

1

Keamanan sering menjadi alasan besar.

— JustinC

1

@JustinC: jelaskan pada saya di halaman terpisah untuk login dengan lebih aman?

— ryanzec

Tidak harus melalui atribut sistem file (tetapi bisa jadi itu yang dibutuhkan oleh situasi), tetapi wadah aplikasi web / perangkat lunak servlet / runtime melalui penerapan metode otentikasi / otorisasi selektif yang diterapkan pada sumber daya tertentu, atau ke grup sumber daya secara keseluruhan (secara praktis, sebuah direktori): untuk halaman login dan sumber daya statis tertentu (gambar, stylesheet, halaman kesalahan), akses anonim seringkali cukup; untuk halaman lain, otentikasi / otorisasi yang lebih khusus mungkin diperlukan.

— JustinC

2

Otentikasi di luar aplikasi mengisolasi otentikasi agar tidak menjadi perhatian aplikasi. Keamanan aktual akan tergantung pada implementasi dan teknologi

— hanzolo

pembaruan 2017: IdentityServer

— hanzolo

10

Salah satu alasan untuk melakukan ini adalah karena Anda kemudian dapat menggunakan sesi berbasis cookie normal. Pengguna login, respons mengirim cookie bersama dengan halaman utama awal ... dan kemudian semua panggilan ajax berikutnya mengirim cookie kembali ke server.

— GrandmasterB
sumber

6

Saya melihat beberapa alasan untuk melakukan ini:

Saya bisa menggunakan aturan kontrol akses berbasis jalur normal di web.xml.
Saya tidak pernah yakin bahwa saya telah melindungi seluruh aplikasi Ajax dengan benar, dan saya perlu melakukan tes ekstensif untuk percaya diri.
Saya bisa mendelegasikan otentikasi ke kerangka kerja (seperti Spring Security), aplikasi pihak ketiga, atau solusi SSO (seperti CAS atau JOSSO).
Saya dapat membiarkan nama cache browser dan (opsional) kata sandi untuk pengguna.

— n0rm1e
sumber