내 SF 1.4 앱에서 memcached (igbinary api 사용)를 구현 중이며 문제가 발생하여 진행 방법에 대한 통찰력이 필요합니다.Symfony 1.4 - sfCacheSessionStorage
기본적으로 sfCacheSessionStorage를 확장하고 다음 메서드를 재정의하는 자체 캐싱 클래스를 만들었습니다. initialize, regenerate 및 shutdown. 나는이 메소드들을 모두 오버라이드 시켜야만했다. 그들은 PHP의 직렬화 API를 호출하지만 대신에 igbinary 직렬화 API를 사용하는 것을 선호한다.
모든 것을 얻은 후에 나는 sfCacheSessionStorage::regenerate()이 세션이 이미 재생성되었는지 여부에 관계없이 자신의 세션 ID를 생성한다는 사실을 발견했습니다. 예를 들어 상위 sfSessionStorage::regenerate() 클래스에는 세션이 이미 다시 생성되었는지 여부를 확인하는 데 사용되는 싱글 톤이 있습니다. 이렇게하면 세션 데이터가 이전에 재생성 된 session_id와 연결되어 있고 새로 생성 된 session_id로 옮겨지지 않아서 세션 데이터가 손실 될 수있는 문제가 방지됩니다.
SF 1.4는 사용자를 인증 (로그인), 로그 아웃, 자격 증명을 지우거나 추가하는 경우 언제든지 regenerate() 메서드를 호출합니다. 내가 가진 문제는 사용자가 인증 된 것으로 표시되고 자격 증명을 지우고 그룹 연결을 추가하는 수신기를 호출하면 세션 데이터가 손실되는 sfCacheSessionStorage::regenerate()에 대한 두 건의 호출이 발생합니다. 그러나 쿠키를 편집하고 세션을 처음 재생성 된 session_id로 설정하면 세션이 예상대로 작동하지만 세션 ID가 새로 생성 된 세션 ID로 인해 세션 데이터가 손실된다는 것이 명확한 자격 증명으로 인한 두 번째 호출입니다.
내 생각은 sfSessionStorage의 논리를 따르고 세션이 이미 재생성되었는지 여부를 확인하기 위해 싱글 톤을 사용하는 것이지만 sfCacheSessionStorage::regenerate() 세션이 EVERYTIME을 재생성하는 이유가있을 수 있습니다. 그래서 제 질문은 싱글 톤 전략을 진행하는 것이 안전한지, 아니면 언제나 재생성을 시도해야합니까? 로그인/아웃하거나 자격증 명을 추가/제거 할 때 session fixation 하이재킹 시나리오를 피하는 것이 유일한 이유는 session_id를 다시 생성해야한다는 것입니다. sfCacheSessionStorage
내 코드에 대한 sfSessionStorage
- 소스 코드가 정확히 동일의 직렬화/때 unserialize 전화에 저장합니다.