2009-08-21 3 views
3

RFC 2109에 따르면 쿠키 값은 "사용자 에이전트에 불투명하며 원본 서버가 보낼 서버 선택 가능한 인쇄 가능한 ASCII 인코딩 일 수 있습니다."C#에서 인코딩 된 쿠키 값 처리

따라서 다른 언어/플랫폼/서버는 원래 값이 같더라도 다른 쿠키 값을 보냅니다.

예를 들어, C#/ASP.NET은 그대로 텍스트를 보냅니다. 고전적인 ASP urlencodes 및 urldecodes 텍스트; Perl/Apache urlencodes /는 텍스트를 디코드합니다 (그러나 ASP와 다르게)! PHP는 당신에게 옵션을 제공합니다.

나는 크게 다른 응용 프로그램과 쿠키를 공유해야하는 싱글 사인온 (SSO) 시스템을 작성 중입니다. 특히 .NET, Java, Perl, ColdFusion을 기본으로 지원해야합니다.

쿠키에 저장하는 텍스트는 항상 유효한 ASCII-7 문자열입니다. 그럼에도 불구하고 Perl은 일부 7 비트 ASCII 문자를 인코딩하는 것을 좋아합니다.

나는 두 가지 대안이 작품을 만들기 위해 참조 :

  1. 만이 아닌 인코딩 된 값을 받아들입니다. 결국에는 인코딩 할 필요가 없습니다. 이것이 바로 지금의 상황입니다. 분명히 모든 통합 시스템은 인코딩되지 않은 값을 지원할 수 있어야합니다.

  2. 인코딩 된 값과 인코딩되지 않은 값을 모두 허용합니다. 이것은 상자 밖에서 최대한의 호환성을 허용 할 것이지만 특정 값이 인코딩되었는지 아닌지를 결정해야합니다 ("% 20"은 "% 20"문자열 또는 공백입니까?)

어떤 솔루션을 제안 하시겠습니까? 그 이유는 무엇입니까? # 2 인 경우 UrlEncoded 텍스트를 어떻게 감지합니까?


쿠키의 예

A5A2794D694241AD92F9B22F288EFAA1|8428DCCC|20090821142732|20090821142832| 
10.100.107.40|955098D50AB4982D4E247EFA53F4E23B32A05ED0131E096709BE1D8CCC 
8A3CA18252D376473C244FD71C462AB42CF54C 

답변

1

순수한 영숫자 값을 사용할 수없는 이유는 무엇입니까? 당신이 유지하려고하는 불투명 한 바이너리 데이터를 가지고 있다면 hex를 사용하거나 "web safe"base64를 사용할 수 있습니다.

누구나 쿠키를 뒤범벅 만들지는 않습니다. 에있는 IMO가 더 좋습니다.

+0

이미 16 진수를 사용 중입니다. 영숫자가 아닌 유일한 문자는 필드를 구분하는 파이프 문자입니다. 이것은 perl로 인코딩되는 것입니다. 다른 한편으로는, 다른 플랫폼에서 내가 아는 모든 캐릭터를 인코딩 할 수 있습니다. 당신은 결코 모른다 : – Sklivvz

+1

만약 당신이 영숫자에 충실하면, 괜찮을거야. | 대신 X를 구분 기호로 사용하십시오. –

3

예, 이것은 사소한 문제가 아니다 (I 추가 한 라인은 적합하게 나누기). 근본적으로, 솔루션 # 2는 더 많은 상호 운용 성을 제공하기 때문에 더 많은 것을 기대합니다. 그러나 말했듯이 URL 인코딩 된 쿠키와 그렇지 않은 쿠키를 탐지하는 것은 사소한 문제입니다.

내 마음에 떠오르는 한 가지 점은 쿠키 문자의 시작 부분에 특수 문자를 사용하여 쿠키가 인코딩되었는지 여부를 감지 할 수 있다는 것입니다. 물론 이것은 모든 클라이언트를 포괄하지는 못하지만 예를 들어 일반적인 쿠키 값이 CookieValue1234의 형식 인 경우 head :CookieValue1234으로 변경하고 그 안에 공간이 인코딩 된 것인지 다시 확인하십시오. (예 : "%20"또는 "").

+0

확실한 해결책은 여러 인코딩을 테스트하려는 경우 여러 테스트 문자를 넣을 수 있다는 것입니다. –