세션 변수를 피해야합니까?

과거에는 세션 변수에 크게 의존했지만 최근에는 쿼리 문자열 매개 변수와 같은 것을 사용하여 많은 변수가 불필요한 것으로 나타났습니다.

동료가 세션 변수 사용을 거부합니다. 이것은 현실적인 목표입니까? 실제적인 이유로 세션 변수를 피해야합니까? 세션 변수를 완전히 피할 수 있습니까 (세션 쿠키는 로그인을 허용하지 않음) 더 나은 디자인이 될까요?

동료가 사용하지 않은 몇 가지 이유는 다음과 같습니다.

• 세션 변수의 형식화되지 않은 특성
• 상태 손실을 유발하는 세션 시간 초과
• 세션 변수의 글로벌 범위 특성
• 세션이 손실되는로드 밸런싱 서버 (.Net에만 해당)
• 응용 프로그램 풀 / 서버 다시 시작
• 그들은 불필요

응용 프로그램에 세션 변수가 있으면 다음과 같이 스스로에게 물어보십시오.

브라우저의 뒤로 버튼을 클릭하면 어떤 값을 변수에 갖기를 원합니까?

답이 "현재 값"이면 세션 변수가 유용 할 수 있습니다. 예를 들어 쇼핑 카트가 있습니다. 이력을 다시 검토 할 때 쇼핑 카트에서 물건이 제거 될 것으로 예상하지 않습니다. 항상 현재 상태입니다.

답이 "이전 값"이면 세션 변수를 사용하지 않아야합니다. 내가 본 나쁜 사용은 페이지 사이에 매개 변수를 전달하는 것을 포함합니다. 뒤로 버튼을 클릭하여 페이지로 돌아 가면 페이지가 반드시 올바른 매개 변수를 가져 오지는 않습니다. 또한 두 개의 탭을 열면 내 사이트는 어떻게 작동합니까?

뒤로 단추 동작을 올바르게 수행한다고해서 반드시 끝이되는 것은 아니지만 웹 사이트를 상태 비 저장 응용 프로그램으로 생각하는 데 도움이됩니다. 일반적으로 세션 변수를 적절하게 사용하는 경우는 거의 없습니다.

HTTP 프로토콜은 상태 비 저장입니다. 세션은 HTTP 요청에서 클라이언트 상태를 유지하는 방법입니다. 플랫폼의 내장 세션 처리를 사용하거나 쿼리 문자열 매개 변수를 사용하여 직접 수행하도록 선택할 수 있습니다. 어느 쪽이든 세션의 개념은 많은 작업에 필요합니다.

동료가 특정 구현을 싫어하거나 의도 한 목적으로 세션을 사용하지 않은 것 같습니다. HTTP 요청에서 특정 클라이언트 연결에 대한 정보를 유지해야하는 경우 일부 세션 지속성이 필요합니다.

다음은 구현 관련 문제입니다.

세션 변수의 형식화되지 않은 특성

세션 변수의 글로벌 범위 특성

세션을 잃는로드 밸런싱 서버

응용 프로그램 풀 / 서버 다시 시작

예를 들어, 대부분 PHP에서 작업하고 세션 정보를 관계형 데이터베이스에 저장합니다. 그래서 내 세션 변수가 입력되었습니다. 로드 밸런싱 및 서버 재시작으로 세션 문제가 발생하지 않습니다.

이것은 더 흥미 롭습니다.

상태 손실을 유발하는 세션 시간 초과

세션은 대부분 쿠키를 통해 유지됩니다. 클라이언트는 언제든지 삭제할 수 있습니다. 그러나 쿼리 문자열 매개 변수를 통해 유지 될 수도 있으므로 클라이언트에서 시간 초과되지 않습니다. 서버 시간 초과는 사용자에게 달려 있습니다. 따라서이 문제조차 구현에 따라 다릅니다.

특정 구현이 마음에 들지 않기 때문에 전체 세션 개념을 버리지 마십시오. 훌륭한 웹 애플리케이션 프레임 워크는 세션을 올바르게 사용하여 사용자 로그인을 유지하거나 사용자의 현재 방문과 관련된 다른 것을 유지합니다. 사용자의 데이터베이스 레코드는 로그인 할 때 특정 정보를 저장하는 데 사용될 수 있으며 사용해야합니다. 그러나 익명 방문자는 최근 방문한 페이지의 짧은 목록 또는 선호하는 사이트와 같은 임시 정보도 세션에 보존 할 가치가 있습니다. 이미 본 통지를 숨 깁니다. 일반적으로 작은 임시 정보 만 세션 저장에 적합합니다.

다른 사람들은 좋은 점을 많이 만들었지 만 (반복을 피할 것입니다) 아직 논의되지 않은 친구의 기술 중 하나 인 보안 .

코드를 보지 않고 어떤 종류의 취약점을 열 었는지는 알 수 없지만 다음은 머리 위로 생각할 수있는 몇 가지 사항입니다.

• 세션 수정 : 사용자가 쿠키를 적절히 설정 한 컴퓨터를 사용하지 않고 URL에 필요한 정보가있는 링크를 클릭하도록하면 약간 더 쉬운 강력한 공격입니다.
• SQL 주입 (또는 기타 악의적 인 입력) : 사용자가 제공 한 것을 신뢰하지 마십시오. 세션 변수는 서버를 떠나지 않는 이점이 있으므로 사용자가 직접 변경할 수 없습니다. 당신이 그것을두기 전에 데이터를 살균한다 반면 에 세션, 당신은 항상 당신이 나중에 꺼내 값을 신뢰할 수 있습니다. 모든 것이 쿼리 문자열을 통해 전달되면 악의적 인 입력을 허용하지 않는지 확인해야하는 많은 검증이 있습니다.
• 위조 된 입력을 사용하여 데이터 손상 : SQL 주입과 유사하게 얼마나 많은 데이터를주고 받습니까? 얼마나 중요합니까? 쿼리 문자열에서 값을 변경하여 앱의 동작을 변경할 수 있습니까? 값을 변경하여 서버의 데이터를 손상시킬 수 있습니까? 서버의 데이터를 손상시킬 경우 다른 사용자에게 영향을 줍니까? 답변이 "아니오"인 경우 제 답변은 " 확실합니까? 확인해야 할 곳이 많이 있습니다"입니다.

세션을 사용할 때 이러한 모든 상황이 여전히 발생할 수 있지만 친구가 자신이하는 일을 모르면 훨씬 쉽게 얻을 수 있습니다 .

세션 변수는 이전 기본 전역 변수와 어느 정도 비슷합니다. 사용자는 자신의 내용, 내용, 범위 및 사용 방법을 추적해야합니다. 이전 버전의 BASIC에서와 동일합니다. 즉, 프로그래밍 모델 (ASP, MVC 등)의 필수적이고 매우 중요한 부분으로 설계된 메커니즘의 사용을 누군가가 왜 완전히 할인하겠습니까?

세션 변수를 사용할 때 내가 겪은 유일한 나쁜 점은 변수를 추적하고 관련 데이터로 채워져 폐기해야한다는 부담을지게한다는 것입니다.

프로그래밍 할 때 우리가하는 일이 아닌가?

나는 세션 변수와 관련된 디버깅 문제가 있었기 때문에 동료처럼 생각 했었습니다. 세션 변수는 실제로 무능했습니다. 예, 쿼리 문자열, 양식의 숨겨진 필드 등을 사용하여 세션 변수없이 어느 정도까지 얻을 수 있습니다. 그러나 응용 프로그램에 상태를 결정하기 위해 가장 기본적인 논리 흐름 이외의 항목이있는 경우이 방법을 사용하면 매우 번거로워집니다. 또한 쿼리 문자열과 숨겨진 필드를 통해 응용 프로그램의 내부 작업을 표시 할 수있는 보안 위험이 있습니다.

세션 변수로 작업 할 때 설정 및 설정 해제 시점을 추적하면 응용 프로그램의 논리 흐름이 결정됩니다. C와 같은 언어의 메모리 관리와 같습니다.

이것은 프레임 워크가없는 비교적 작은 프로젝트에서 PHP로 작업 한 경험에 의한 것이므로 다른 플랫폼에서는 상황이 다를 수 있지만 일반적인 원칙은 여전히 ​​적용된다고 생각합니다.

앞에서 언급했듯이 HTTP는 Stateless이며 Session Variable은이를 중단합니다. 상태 비 저장 형 HTTP 디자인은 리소스 캐싱에 도움이됩니다. 공개적으로 이용 가능한 리소스

세션 변수없이 웹 사이트를 디자인 할 수는 있지만 더 어렵습니다. 가장 어려운 (IMHO)는 멋진 로그인 / 로그 아웃이며 HTTP 인증 체계는 HTML 양식을 통해 인증하는 데 필요한 도구를 제공하지 않습니다 (javascript-XHR을 사용하여 https : // untel : passowrd@mydomain.com ) 로그 아웃하고 브라우저 간 호환이 더 어렵습니다. 그것에 대한 w3 메일 링리스트에 대한 토론이 있었지만, 내가 올바르게 기억한다면 아이디어가 떨어졌습니다.

나머지는 세션 변수없이 살 수 있어야합니다. 데이터베이스, 파일 또는 어느 곳에서나 상태가 있지만 세션 변수 사용은 거의 없습니다.

사용자에게 장바구니가있는 경우 장바구니를 공유하지 않고 두 대의 컴퓨터 / 브라우저를 탐색 할 수있는 경우에만 가변 세션입니다.