SPA의 로그인 페이지를 SPA의 페이지가 아닌 별도의 페이지로 만드는 것이 왜 인기가 있는지 궁금합니다 (로드 및 ajax 요청을 통해 데이터 보내기)?
내가 생각할 수있는 것은 보안 뿐이지 만 특정 보안 이유는 생각할 수 없습니다. SPA의 일부인 로그인 페이지가 ajax를 통해 사용자 이름 / 암호를 보내면 방화범이나 웹 관리자와 같은 도구로 볼 수 있지만 정상적인 경우에도 마찬가지입니다. POST 요청에는이 데이터를 쉽게 캡처 할 수있는 다른 도구 (예 : 피들러, httpscoop 등)가 있습니다.
내가 놓친 것이 있습니까?
답변
아마도 응용 프로그램에만 필요한 많은 클라이언트 측 자산 (예 : 무거운 JavaScript 프레임 워크, 이미지 등 )을 로드하는 것을 절약 할 수 있습니다.
유사한 성능 목표를 달성 할 수있는보다 정교한 방법이 있습니다 ( ” Malte Ubl & John Hjelmstad : JavaScript 로딩에 대한 새롭고 효율적인 접근 방법-JSConf EU 2012 “참조). 어쨌든 웹 앱은 거의 모든 자산을 사용합니다.
http://infogr.am 베타 와 같은 사이트에서 야생에서 이것을 볼 수 있습니다 .
- http://infogr.am/login/은 jquery , raphael , 사용자 정의 js 및 3 개의 CSS 파일을로드합니다.
- http://infogr.am/beta/ (응용 프로그램의 기본 SPI 페이지)는 10 개의 자바 스크립트 프레임 워크, 5 개의 외부 CSS 파일 및 약 60 개의 이미지를로드합니다.
답변
나는 합리적이거나 반대되는 몇 가지 논쟁이 있다고 생각하며, 기술이 결정에 중요한 역할을한다고 말하고 싶습니다.
별도의 로그인 “페이지”가 있으면 “디렉토리 보안”을 사용할 수 있다고 주장 할 수 있습니다. 일반적으로 누구나 “페이지”로그인을 볼 수 있지만 인증 된 사용자 만 “페이지”응용 프로그램과 “디렉토리”를 볼 수 있습니다. / Account /가 / App /와 다르고 각각 자체 보안 “프로필”이있는 경로도 잠글 수 있습니다.
또한 SPA 접근 방식을 사용하고 인증을 응용 프로그램 경험과 혼합하는 경우 논리가 복잡해질 수 있습니다. 사용자가 “여기에 있기 때문에 로그인되어”있다고 가정하는 대신, 인증 상태를 지속적으로 확인하고 “이 사용자가 여기에 있어야합니까?”
또한 로그인 페이지는 일반적으로 소비자를 향한 사이트에 있습니다. www.yourapp.com으로 이동 한 후 로그인 페이지에서 정보, 연락처, 지원 등에 대한 정보와 “로그인”페이지가 있습니다. 인증을 통해 전체 대상 호스트로 리디렉션 할 수 있습니다.
별도의 로그인 페이지를 유지하는 이유와 실제로 “소비자 대면”사이트에 대해 완전히 다른 앱을 사용하는 이유는 인증되지 않은 사용자에게는 거의 노출되지 않기 때문입니다. 우연히 일부 moron이 내 로그인 페이지에서 뱅킹을 시작하기 때문에 앱의 측면에 영향을 미치고 싶지는 않습니다. 로그인이 단순한 인증 조회 만 수행하는 경우에도 .. 최악의 경우 소비자 사이트가 다운되어 아무도 로그인 할 수 없지만 로그인 한 사용자는 알지 못하고 경험이 느려지기 시작하지 않습니다. 인증되지 않은 영역에 대한 위험을 격리했습니다 ..
답변
이렇게하는 한 가지 이유는 일반 쿠키 기반 세션을 사용할 수 있기 때문입니다. 사용자가 로그인하고 응답이 초기 메인 페이지와 함께 쿠키를 보낸 다음 모든 후속 ajax 호출이 쿠키를 서버로 다시 보냅니다.
답변
몇 가지 이유가 있습니다.
- web.xml에서 일반적인 경로 기반 액세스 제어 규칙을 사용할 수 있습니다.
- 전체 Ajax 애플리케이션을 올바르게 보호했는지 확신 할 수 없으며 자신감을 갖기 위해 광범위한 테스트를 수행해야합니다.
- 인증을 프레임 워크 (예 : Spring Security), 타사 응용 프로그램 또는 SSO 솔루션 (예 : CAS 또는 JOSSO)에 위임 할 수 있습니다.
- 브라우저가 사용자의 사용자 이름과 암호를 캐시하도록 할 수 있습니다.