2011-11-01 28 views
19

Tôi gặp sự cố với ứng dụng CakePHP của mình. Điều này dường như chỉ xảy ra trong IE và chỉ trên một số máy tính nhất định. Nó là phù hợp trên các máy tính mà nó đang xảy ra mặc dù.Cookie CakePHP/Số sự cố phiên

Số phát hành: Người dùng đã đăng nhập và trên trang https://example.com/users/view và nhấp vào đăng xuất. Người dùng được chuyển hướng đến http://example.com và dường như bị đăng xuất cho đến khi người dùng truy cập vào trang https khác và họ vẫn đăng nhập. Họ có thể nhấp vào đăng xuất bao nhiêu lần tùy thích nhưng họ luôn đăng nhập trên https và chỉ đăng xuất http.

Issue hai: người dùng đăng nhập vào https://example.com/users/signin họ đang chuyển hướng đến http://example.com và bây giờ dường như đang đăng nhập tài khoản đi vào https://example.com/admin/slides và không biết điều đó nhưng bây giờ được đăng xuất, nhấp vào bất kỳ trang nào khác (. hoặc chỉ cần làm mới trang hiện tại của họ) sẽ yêu cầu họ đăng nhập lại.

Tôi không biết điều gì đang diễn ra. Tôi đã đọc và thử các giải pháp được mô tả trên cả hai vấn đề tương tự nhau: Session not saving when moving from ssl to non-sslCookie not renewing/overwriting in IE nhưng tôi vẫn gặp sự cố tương tự.

Đầu mối duy nhất mà tôi đã chú ý đến (và tôi không biết nếu điều này có nghĩa là bất kỳ điều gì) là khi tôi gỡ lỗi cả $_SESSION$this->Session->read() trên trang HTTP LUÔN chỉ $ this-> Session-> read() trả về giá trị. trên các trang HTTPS một số LUÔN trả về cùng một giá trị cho cả hai, những người khác LUÔN LUÔN chỉ trả lại một giá trị cho $ this-> Session-> read().

Ví dụ: http://example.comhttps://example.com/users không bao giờ thấy $ _SESSION, https://example.com/carts luôn thấy $ _SESSION. Tôi không chắc nhưng tôi nghĩ rằng có thể các trang an toàn được cho là đang nhìn thấy nó và vì một số không thể có điều gì đó sai, tuy nhiên khi tôi kiểm tra mã, tôi thấy không có sự khác biệt nào có thể gợi ý lý do tại sao t.

Ngoài ra, nếu tôi thêm $this->Session->destroy() vào beforeFilter trong AppController, thì tất cả các trang ngay cả HTTP đều có thể thấy $ _SESSION. Tôi không thực sự sử dụng $ _SESSION trong ứng dụng của tôi, tôi chỉ nghĩ rằng đây có thể là một đầu mối cho những gì sai.


CẬP NHẬT

tôi tooked lời khuyên Gustav Bertram và nhìn vào chuỗi tác nhân người dùng. Tôi đã so sánh chuỗi tác nhân người dùng với IE trên máy tính đang gặp sự cố với IE trên máy tính không gặp sự cố. Họ giống nhau, ngoại trừ một vấn đề đang gặp phải vấn đề "khung google chrome" trong chuỗi tác nhân người dùng. Tôi đã gỡ cài đặt Google Chrome Frame khỏi máy tính đó, đã khởi động lại, đã thử lại và sự cố dường như đã được giải quyết.

Nếu đây là nguyên nhân thực sự, thì giải pháp đơn giản sẽ khiến người dùng gỡ cài đặt khung Chrome. Tuy nhiên tôi tự hỏi nếu có một công việc xung quanh đó sẽ cho phép họ có khung chrome được cài đặt và vẫn làm việc.

+0

(Tôi cho rằng bạn đã loại bỏ các nghi phạm bộ nhớ cache thông thường.) Phiên bản nào của IE? Không tinkering với tiêu đề trang (bộ nhớ cache kiểm soát, vv - xem http://support.microsoft.com/kb/234067) có bất kỳ tác động? – OpenSorceress

+0

Nội dung phiên có bị xáo trộn hay không? Có thể là các tùy chọn bảo mật .. – Dunhamzzz

+0

Trang có bất kỳ nội dung flash nào không? Bạn đã thử thay đổi bảo mật phiên từ HIGH thành LOW chưa? – binoy

Trả lời

16

Hãy thử thêm dòng sau vào tập tin core.php của bạn:

Configure::write('Session.checkAgent', false); 
Configure::write('Session.ini',array('session.cookie_secure' => false, 'session.referer_check' => false)); 

Những thông số này nên buộc cookie để tồn tại thậm chí thông qua Google Chrome Frame. Điều này sẽ đặt cả cài đặt của PHP và CakePHP để cho phép cookie tồn tại lâu hơn http và https.

+0

Tôi nghĩ rằng đây là những thông số CakePHP 2.0. Chúng có thể hơi khác một chút trong 1.3, nhưng nên cho phép bạn điều hướng giữa http và https khi đã đăng nhập. –

+0

Có vẻ như cú pháp giống như 1.3, hoạt động ở 1.3 không có lỗi. :) Điều này dường như khắc phục sự cố ngay cả khi khung chrome được cài đặt. Bạn có biết tại sao Cake lại kiểm tra đại lý ngay từ đầu? Xin lỗi tôi đã tặng tiền thưởng rồi sắp hết rồi. –

+0

Đó là biện pháp bảo mật. Tôi nghĩ rằng theo mặc định, nó muốn một cookie an toàn chỉ hợp lệ trong một kết nối an toàn. Nếu bạn đi đến http, sau đó nó không an toàn nữa. Vì vậy, ở đây, chúng tôi về cơ bản biến nó đi. Không phải lo lắng về tiền thưởng. Tôi vui vì bạn đã làm nó hoạt động! –

6

Đề xuất của tôi là bạn hãy xem trực tiếp các gói, để xem điều gì đang xảy ra với cookie.

Cài đặt Wireshark trên máy khách của bạn và kết nối với máy chủ web từ xa. (Wireshark sẽ bỏ qua lưu lượng truy cập localhost.)

Nghi ngờ của tôi là cookie của bạn bị xáo trộn (tôi đã từng có một số cookie bị PHP cắt xén!) hoặc chúng bị kẹt (đó sẽ là lỗi của IE). Dù bằng cách nào, bạn sẽ có thêm thông tin về những gì đang xảy ra.

Như một phương sách cuối cùng, hãy kiểm tra chuỗi tác nhân người dùng trong mã cho phiên bản IE không được hỗ trợ/không được hỗ trợ và yêu cầu mọi người nâng cấp.

+0

Tôi đang trao cho bạn tiền thưởng từ đề xuất của bạn về nhìn vào tác nhân người dùng là điều đã dẫn đến việc tôi tìm ra vấn đề khung chrome. Tôi vẫn muốn tìm ra một cách để làm cho nó hoạt động với khung chrome được cài đặt mặc dù. –

+0

Dường như bạn có thể chèn thẻ để [buộc IE với Google Chrome sử dụng công cụ kết xuất của Chrome] (http://www.zdnet.com/blog/google/google-chrome-frame-hijacks-ie-and-is- hiện được coi là ổn định/2485). Nếu điều đó không cung cấp cho bạn niềm vui, nó có thể là thời gian báo cáo lỗi. –

-1

Bạn đã đảm bảo rằng bạn không có bất kỳ dấu cách hoặc dòng mới nào sau khi đóng thẻ php?>? Có lẽ đó là điều đầu tiên bạn kiểm tra, nhưng từ kinh nghiệm tôi biết rằng các thẻ php bị đóng nặng không gây ra các vấn đề lẻ tẻ với việc xử lý phiên php.

0

Hãy thử đặt điều này trong bộ lọc trước của AppController và xem nó có làm gì không. Tôi có cảm giác rằng cài đặt cookie không được định cấu hình như bạn cần. See here để biết thêm thông tin.

function beforeFilter() { 
    $this->Cookie->domain = '.example.com'; 
    $this->Cookie->secure = false; 
}