중복으로 표시 될 가능성이 높지만 원하는 것을 정확히 찾을 수 없습니다.

이것은 일반적인 문제이며 잘 정의 된 모범 사례 솔루션이 있다고 확신합니다.

배경

1. 단일 페이지 SaaS 앱에는 많은 끌어서 놓기가 있으며 사용자는 일정 시간 동안 많은 서버 통신 없이도 상호 작용할 수 있습니다

2. 서버 세션은 비 영구 세션 쿠키를 사용하여 사용자 개체 만 보유합니다.

3. X 시간 후 서버에서 세션이 만료 됨

4. 일부는 로그인 중에 만로드됩니다

문제

1. 사용자가 앱에서 작업을 마치면 로그 아웃하지 않고 브라우저를 계속 열어 둡니다.
2. X 시간 이상 후에 사용자가 다시 방문 함 (서버에서 세션이 무효화 됨)
3. 사용자는 서버 연결없이 앱과 상호 작용 (드래그 앤 드롭, 텍스트 편집 ...)
4. 다음 서버 상호 작용에서만 (자동 저장이 없다고 가정하자) 사용자가 로그인 페이지에 던져지고 일부 작업이 손실 됨

가능한 해결책

여기에 내가 생각한 몇 가지 해결책이 있습니다. 다른 것들이 있고 근본적으로 문제가있는 경우 듣고 싶습니다.

1. 절대 사용자를 로그 아웃하지 마십시오

• 어떻게? 긴 세션을 유지하거나 영구 쿠키를 유지하거나 javaScript "live a keep"핑
• 장점 : 사용자는 아무것도 걱정할 필요가 없으며 문제를 해결합니다.
• 단점 : PCI와 호환되지 않고 안전하지 않으며 개발 변경이 필요합니다. 예를 들어 사용자 로그인시에만 세션에로드 된 항목은 pub 하위 모델로 이동하거나 (이벤트 변경 사항을 청취) 캐시 시간이 초과되어야합니다.

2. 로컬 스토리지

• 어떻게? 새 로컬 스토리지를 사용하여 로그 아웃 된 상태를 일시적으로 저장하고 로그인 페이지로 리디렉션하고 로그인 한 후에도 지속
• 장점 : 세션 시간 제한을 처리하는 것이 아니라 "오프라인 작업"지원을위한 기반
• 단점 : 구현하기가 어려우며 모든 브라우저가 지원하지는 않지만 데이터 트리의 상태 병합을 수행해야합니다.

3. 자동 저장

모델을 변경하는 모든 사용자 작업은 즉시 (또는 일종의 클라이언트 쪽 대기열을 통해) 유지되어야합니다. 예를 들어 확인란을 선택하거나 텍스트 필드를 변경하거나 작업이 완료되면 끌어다 놓으면 변경 사항이 유지됩니다.

• 어떻게? MV ** 프레임 워크 (Backbone.js / Knockout.js / Ember.js / Angular.js 등)를 사용하여 모델을 바인딩하고 변경 사항을 유지하십시오.
• 장점 : 깨끗한 솔루션처럼 보입니다. 사용자가 활동하는 한 세션이 활성 상태이며 클라이언트 측 작업은 지속되지 않습니다.
• 단점 : 세션 시간이 초과 된 후 사용자가 마지막으로 수행 한 작업입니다.

4. 세션이 만료 된 후 사용자를 로그 아웃하십시오.

이것은 몇 가지 접근 방식을 가질 수 있습니다

1. 서버에게 "세션이 만료되었습니다"라고 물어보십시오. 이것은 서버에 대한 단순한 질문이 세션을 연장하기 때문에 약간의 캐치 22 / Schrodinger의 고양이입니다.

   • 어떻게? 그러한 질문을 지원하는 서버가 있거나 (아무것도 모르지만 Java 랜드로 제공됨) 세션 ID 테이블과 마지막 액세스 시간을 수동으로 유지하고 세션을 전달하여 서버에 요청할 수 있습니다 쿠키 대신 매개 변수로 ID를 사용하면 이것이 가능한지 확실하지 않지만 위험하고 안전하지 않으며 나쁜 디자인 whatsever.login 페이지는 로그인 한 후에도 지속됩니다.
   • 장점 : 서버에서 이러한 기본 지원이 있었다면 깨끗하고 합법적 인 질문처럼 들립니다 (사용자 X가 여전히 세션을 가지고 있는지 여부를 묻는 경우).
   • 단점 : 서버가 서버를 지원하지 않으면 (그리고 서버 나 프레임 워크 에이 기능이 있는지 모르겠습니다) 해결 방법에는 잠재적으로 큰 보안 위험이 있습니다.

2. 내가 들었던 한 가지 해결 방법은 서버 측에서 세션이 짧고 클라이언트 측 핑을 유지하는 것입니다.

   • 어떻게? 서버의 짧은 세션, 클라이언트는 모든 sessionTimeOut / 2를 ping합니다. 최대 재시도 횟수는 Y입니다.
   • 장점 : 문제가 빠르고 더러워 짐
   • 단점 : 해킹처럼 느껴 서버가 세션을 갱신하지 않고 직접 세션 갱신을 처리합니다.

3. 클라이언트 측 타이머

   • 어떻게? 클라이언트 측에 타이머가 있고 모든 요청에서 최대 서버 세션 시간 제한에서 패딩을 뺀 값과 같도록 모든 요청을 다시 시작하여 타이머를 서버와 동기화합니다. 사용자가 서버에 요청을 보내지 않은 후 UI에 "세션이 있습니다. 시간이 초과 될 예정입니까? 계속 하시겠습니까? " (당신은 온라인 뱅킹에있는 것처럼)

   • 장점 : 문제 해결

   • 단점 : 동기화가 작동하는지 확인하는 것 외에는 생각할 수 없습니다.

질문

위의 분석에서 누락 된 부분이 있거나 어리석은 실수가있을 수 있으며 문제를 해결하기 위해 귀하의 도움을 원합니다. 이를 위해 어떤 다른 솔루션을 사용할 수 있습니까?

가장 일반적인 간단한 해결책은 클라이언트가 타이머를 설정하여 정상적인 시간 초과 창의 특정 부분이 지나간 후에 메시지를 표시 한 다음 아무런 조치를 취하지 않으면 세션이 만료되기 직전에 강제로 로그 아웃하는 것입니다.

로컬 스토리지 및 자동 저장은 트랜잭션과 관련된 몇 가지 문제와 실제로 저장된 의미를 소개합니다. 나는 사용자 기반이 배후의 메커니즘을 이해하지 못할 때 가치가있는 것보다 더 많은 문제로 판명 된 꽤 많은 프로젝트를 진행해 왔습니다.

규정에 따라 로그 아웃 할 수는 없지만 누군가가 예기치 않게 로그 아웃 된 경우 발생하는 상황을 올바르게 처리하지 못하는 실수로 이어질 수 있습니다. "활동적인"사용자.

내가 들었던 한 가지 해결 방법은 서버 측에서 세션이 짧고 클라이언트 쪽 핑을 계속 유지하는 것입니다.

어떻게? 서버의 짧은 세션, 클라이언트는 모든 세션 시간 / 2를 핑 (ping)합니다.

이것이 제 생각에는 최상의 솔루션입니다. 왜 "더러운 해킹"이라고 생각하십니까?

해야 할 일을 정확하게 만듭니다. 사용자가 프로그램으로 작업하는 동안 세션은 열린 상태로 유지됩니다.

사용자가 프로그램 작업을 중단하면 세션이 닫힙니다.

구현하기에 충분히 간단합니다.

질문을 올바르게 이해했다면 정확히 필요한 것입니다.

실제로 이것을 다루는 응용 프로그램을 만들고 있습니다.

Django, Guradian 및 Tastypie를 사용하여 RESTful 서비스를 만드는 것으로 시작했습니다. APIKEY 만 사용하여 인증하며 개체에 대한 권한 부여는 Guardian에서 처리합니다.

django 앱에는 base.html을로드하는 하나의 템플릿보기 urlconf 만 있습니다 ...

클라이언트 쪽에서 Angular를 사용하여 응용 프로그램을 만들었습니다.

인증이 진행되는 한 401 응답을 수신하는 http-auth-interceptor가 있습니다.

401이 수신되면 발신 요청을 버퍼링하고 "로그인 필요"이벤트를 발생시킵니다. 여러 번 발생할 수 있습니다.

"로그인 필요"이벤트가 들릴 때 표시되는 로그인 양식을 포함하는 모달 팝업이 있으며 APIKEY를 포함하는 사용자 자원 (JSON 번들)을 리턴하는 로그인을 수행합니다.

이전에 401 응답을 초래 한 모든 버퍼링 된 요청은 이제 Authorization http 헤더에 포함 된 APIKEY와 함께 재생됩니다.

로컬 스토리지 JSON 데이터를 관리하기 위해 다른 각도 서비스 / 팩토리를 사용하며 여기에서 사용자 이름과 apikey를 저장합니다.

해결해야 할 유일한 퍼즐 조각은 해당 정보를 보호하는 방법과 해당 정보에 시간 초과를 적용하는 방법입니다.

아마도 마지막으로 유효한 http 요청에서 타임 스탬프 검사를 사용했을 것입니다.

제 경우에는 4.1과 비슷한 것을 사용하고 있습니다. 사용자가 매우 가벼운 각도 구동 AJAX json 요청을 서버에 대해 설정된 간격으로 REST API에 로그인 한 후. 보안 요구 사항으로 인해 독점 UI는 서버 측에서 보호 된 정보, 템플릿, 데이터 등을 저장하는 사용자 세션을 서버가 유지할 것으로 예상합니다. 이것은 여전히 ​​보안 관점에서 내가 선호하는 방법입니다. 해시 된 암호 등이 아닌 민감한 데이터를 처리 할 때 클라이언트 쪽을 로컬 저장소에 저장하는 등의 IMO는 서버 쪽보다 위험이 더 큽니다 (누군가가 저와 논쟁을하게 될 것입니다). 타사는 시스템과 통신 할 때 동일한 API를 사용하지만 모든 요청에 ​​대해 인증 자격 증명을 보내야합니다.

서버의 세션에는 최대 유휴 수명이 적용되고 세션 스토리지 엔진은 memcached (메모리 세션이 만료 된 것으로 표시되는 시점에 최대 수명이 적용됨)입니다. 수명은 응용 프로그램에서 추상화 한 세션 수명보다 클 필요가 있습니다 (내 필요는 없습니다). EG 서버에 관한 한 세션이 48 시간 동안 유휴 상태가 될 때까지 세션이 만료되지 않을 수 있지만 코드는 실제 수명을 제어합니다. 수명이 너무 길면 세션 관리가 제대로 수행되지 않으면 리소스 문제가 발생할 수 있습니다.

필자의 경우 조직 내 역할에 따라 다른 사용자가 다른 세션 유휴 시간 초과를 가질 수 있습니다. 서버는 세션 수명에 최대 제한을 두지 만 사용자 정의 제한이 제한보다 작 으면 정상적으로 작동합니다. 서버가 세션을 만료하면 세션 만료 프로세스가 이미 응용 프로그램에서 정상적으로 처리되었으므로 문제가 발생합니다. 이것은 내가 구축 한 비즈니스 응용 프로그램 종류의 요구 사항입니다.

사용자 세션이 유휴 상태이고 응용 프로그램이 지정한 임계 값 내에 있으면 API는 UI에 카운트 다운 대화 상자 (은행처럼)를 표시하고 만료 후 특정 시간 거리 내에 있으면 우아하게 UI에 지시합니다. 사용자를 로그 아웃합니다. 이 기능은 서버가 제어하기 때문에 브라우저 창에서 유지되며 모든 창에서 유휴 이벤트는 정상 타이머 및 자동 로그 아웃 프로세스를 시작하고 동기화 상태를 유지합니다.

우연히 세션이 부적절하게 만료되면 (세션이 memcached에 덤프 됨) 서버에 영향을주는 다음 요청은 사용자에게 알리고 다시 정사각형으로 이동시킵니다 (드물게 발생하지만 가능).