2013-02-24 39 views
8

Tôi đang gặp khó khăn để tìm ra tiêu chuẩn (hoặc có bất kỳ?) Nào để mã hóa/giải mã các giá trị cookie bất kể nền tảng phụ trợ.Các tiêu chuẩn mã hóa/giải mã cookie độc ​​lập Ngôn ngữ

Theo RFC 2109:

Giá trị được đục vào user agent và có thể bất cứ điều gì các máy chủ gốc chọn để gửi, có thể trong một bảng mã ASCII in server-chọn. "Opaque" ngụ ý rằng nội dung chỉ quan tâm và liên quan đến máy chủ gốc. Thực tế, nội dung có thể đọc được bởi bất kỳ ai kiểm tra tiêu đề Set-Cookie.

có vẻ như "máy chủ là sếp" và quyết định mã hóa nào sẽ áp dụng. Điều này làm cho nó khá khó khăn để thiết lập một cookie từ, nói PHP phụ trợ và đọc nó từ Python hoặc Java hoặc bất cứ điều gì, mà không cần viết bất kỳ mã hóa bằng tay/giải mã xử lý trên cả hai mặt.

Giả sử chúng tôi có giá trị cần phải được mã hóa. Nga /"печенье (*} значения"/ có nghĩa là "giá trị cookie" với một số ký tự không phải là số alpha bổ sung trong đó.

Python:

Hầu hết các máy chủ WSGI cũng làm như vậy và sử dụng lớp SimpleCookie Python rằng mã hóa đến/giải mã từ octal literals mặc dù nhiều nói rằng octal literals are depreciated trong ECMA-262, chế độ nghiêm ngặt. Wtf?

Vì vậy, giá trị cookie liệu của chúng tôi trở nên "/\"\320\277\320\265\321\207\320\265\320\275\321\214\320\265 (*} \320\267\320\275\320\260\321\207\320\265\320\275\320\270\321\217\"/"

Node.js:

đã không được kiểm tra ở tất cả nhưng tôi chỉ đoán một backend JavaScript sẽ làm điều đó với mẹ đẻ encodeURIComponentdecodeURIComponent chức năng sử dụng hexadecimal thoát/không thoát?

PHP:

PHP áp dụng urlencode với các giá trị cookie mà là tương tự như encodeURIComponent nhưng không hoàn toàn giống nhau.

Vì vậy, giá trị thô trở nên; %2F%22%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D1%8C%D0%B5+%28%2A%7D+%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D1%8F%22%2F thậm chí không được bao gồm với dấu ngoặc kép.

Tuy nhiên; nếu JavaScript value biến có giá trị PHP mã hóa trên, decodeURIComponent(value) cho /"печенье+(*}+значения"/, xem "+" ký tự thay vì không gian ..

tình hình trong Java, Ruby, Perl và .NET là gì? Ngôn ngữ nào đang theo dõi (hoặc gần nhất) đối với hành vi mong muốn. Trên thực tế, có bất kỳ tiêu chuẩn cho điều này được xác định bởi W3?

Trả lời

4

Tôi nghĩ bạn đã có một vài thứ lộn xộn ở đây. Mã hóa của máy chủ không quan trọng đối với khách hàng và không nên. Đó là những gì RFC 2109 đang cố gắng nói ở đây.

Khái niệm về cookie trong http tương tự như thế này trong cuộc sống thực: Khi thanh toán phí vào cửa câu lạc bộ bạn sẽ có được một dấu mực trên cổ tay. Điều này cho phép bạn rời khỏi và nhập lại câu lạc bộ mà không phải trả tiền nữa. Tất cả những gì bạn phải làm là đưa cổ tay của bạn vào bouncer.Trong ví dụ thực tế này, bạn không quan tâm nó trông như thế nào, nó thậm chí có thể vô hình trong ánh sáng bình thường - tất cả những điều quan trọng là người phát hiện nhận ra điều đó. Nếu bạn đã rửa sạch nó, bạn sẽ mất đặc quyền tái nhập câu lạc bộ mà không phải trả tiền một lần nữa.

Trong HTTP cùng một điều đang xảy ra. Máy chủ đặt cookie với trình duyệt. Khi trình duyệt quay lại máy chủ (đọc: yêu cầu HTTP tiếp theo), trình duyệt sẽ hiển thị cookie cho máy chủ. Máy chủ nhận ra cookie và hành động tương ứng. Một cookie như vậy có thể đơn giản như một điểm đánh dấu "WasHereBefore". Một lần nữa, điều quan trọng là trình duyệt hiểu nó là gì. Nếu bạn xóa cookie của mình, máy chủ sẽ hoạt động như thể nó chưa từng thấy bạn trước đây, giống như bouncer trong câu lạc bộ đó nếu bạn quét sạch con tem mực đó.

Hôm nay, rất nhiều cookie chỉ lưu trữ một phần thông tin quan trọng: một số nhận dạng phiên. Mọi thứ khác được lưu trữ phía máy chủ và được liên kết với số nhận dạng phiên đó. Ưu điểm của hệ thống này là dữ liệu thực tế không bao giờ rời khỏi máy chủ và như vậy có thể được tin cậy. Mọi thứ được lưu trữ phía máy khách đều có thể bị giả mạo và không đáng tin cậy.

Edit: Sau khi đọc bình luận của bạn và đọc câu hỏi của bạn một lần nữa, tôi nghĩ rằng cuối cùng tôi đã hiểu tình hình của bạn, và tại sao bạn quan tâm đến mã hóa thực tế của cookie thay vì chỉ để lại nó với ngôn ngữ lập trình của bạn: Nếu bạn có hai môi trường phần mềm khác nhau trên cùng một máy chủ (ví dụ: Perl PHP), bạn có thể muốn giải mã một cookie được đặt bởi ngôn ngữ khác. Trong ví dụ trên, PHP phải giải mã cookie Perl hoặc ngược lại.

Không có tiêu chuẩn về cách dữ liệu được lưu trữ trong cookie. Tiêu chuẩn chỉ cho biết trình duyệt sẽ gửi lại cookie chính xác như đã nhận được. Lược đồ mã hóa được sử dụng là bất kỳ ngôn ngữ lập trình nào của bạn đều phù hợp.

Quay trở lại ví dụ thực tế về cuộc sống, bây giờ bạn có hai bouncers nói tiếng Anh, một người nói tiếng Nga khác. Cả hai sẽ phải đồng ý về một loại tem mực. Nhiều khả năng điều này sẽ không liên quan đến ít nhất một trong số họ học ngôn ngữ của người khác.

Vì hành vi của trình duyệt được chuẩn hóa, bạn có thể bắt chước một chương trình mã hóa ngôn ngữ bằng tất cả các ngôn ngữ khác được sử dụng trên máy chủ của bạn hoặc đơn giản tạo lược đồ mã hóa chuẩn của riêng bạn. Bạn có thể phải sử dụng các thường trình mức thấp hơn, chẳng hạn như header() của PHP thay vì các thường trình mức cao hơn, chẳng hạn như start_session() để đạt được điều này.

BTW: Theo cách tương tự, đó là ngôn ngữ lập trình phía máy chủ quyết định cách lưu trữ dữ liệu phiên phía máy chủ. Bạn không thể truy cập vào số CGI::Session của Perl bằng cách sử dụng mảng $_SESSION của PHP.

+0

+1 cho mực vô hình! Mặc dù cookie rất tốt có thể được sử dụng để chia sẻ dữ liệu có cấu trúc giữa các máy chủ trên một và cùng một tên miền. – flup

+0

vâng, ví dụ tốt. Tôi rất muốn tặng tiền thưởng này, nếu nó trả lời câu hỏi trong phần ** đậm **. anyways, cookie sẽ có thể được đọc qua nền tảng bất cứ loại dữ liệu mà họ mang .. buồn và đau trong ass. – kirpit

+0

Tôi nghĩ rằng cuối cùng tôi đã hiểu câu hỏi của bạn và chỉnh sửa câu trả lời của tôi cho phù hợp. – Hazzit

2

Bất kể cookie nào bị mờ đối với ứng dụng khách, nó vẫn cần phải tuân theo thông số HTTP. rfc2616 chỉ định rằng tất cả các tiêu đề HTTP phải là ASCII (ISO-8859-1). rfc5987 mở rộng để hỗ trợ các bộ ký tự khác, nhưng tôi không biết nó được hỗ trợ rộng rãi như thế nào.

+0

ASCII là tập hợp con (phần dưới) của ISO-8859-1 – flup

+0

@flup, bạn nói đúng. Nếu tôi hiểu chính xác rfc, nó thực sự mong đợi ASCII. – ykaganovich

0

Tôi thích mã hóa thành UTF8 và được bọc bằng mã hóa base64. Nó nhanh chóng, phổ biến và sẽ không bao giờ mang dữ liệu của bạn ở hai đầu.

Bạn sẽ cần đảm bảo chuyển đổi rõ ràng thành UTF8 ngay cả khi gói nó. Các ngôn ngữ khác & runtimes, trong khi hỗ trợ Unicode, có thể không lưu trữ các chuỗi như UTF8 nội bộ ... giống như nhiều API của Windows. Python 2.x, theo kinh nghiệm của tôi, hiếm khi nhận được chuỗi Unicode ngay mà không cần chuyển đổi rõ ràng.

MÃ HÓA: nativeString -> utfEncode() -> base64Encode()

GIẢI MÃ: base64Decode() -> utfDecode() -> nativeString

Hầu hết các ngôn ngữ tôi biết, những ngày này, hỗ trợ này . Bạn có thể tìm kiếm một mã hóa chức năng đơn phổ quát, nhưng tôi rất thận trọng và chọn cách tiếp cận hai bước ... đặc biệt là với các bộ ký tự nước ngoài.

Các vấn đề liên quan