2008-08-29 7 views
10

Tại sao bạn làm một bài đăng HTML tự động thay vì chuyển hướng đơn giản?Tại sao chuyển hướng dạng HTML được sử dụng trong OpenID 2?

Đây có phải là nhà phát triển có thể tự động tạo biểu mẫu đăng nhập để đăng thư mục lên máy chủ từ xa khi OpenID được biết không?

ví dụ:

  1. Người dùng chưa đăng nhập và truy cập trang đăng nhập của bạn.
  2. Bạn phát hiện OpenID của người dùng từ cookie.
  3. Biểu mẫu được tạo trực tiếp gửi tới máy chủ OpenID từ xa.
  4. Máy chủ từ xa chuyển hướng người dùng trở lại trang web.
  5. Nhật ký trang web trong người dùng.

Nếu đây là trường hợp tôi có thể thấy lợi ích. Tuy nhiên điều này giả định rằng bạn giữ openID của người dùng trong một cookie khi họ đăng xuất.

Tôi có thể tìm thấy rất ít thông tin về cách triển khai thông số này tốt nhất.

Xem HTML MẪU Redirection trong thông số kỹ thuật chính thức:

http://openid.net/specs/openid-authentication-2_0.html#indirect_comm

Tôi thấy điều này ra từ nhìn vào PHP OpenID Library (phiên bản 2.1.1).

// Redirect the user to the OpenID server for authentication. 
// Store the token for this authentication so we can verify the 
// response. 

// For OpenID 1, send a redirect. For OpenID 2, use a Javascript 
// form to send a POST request to the server. 
if ($auth_request->shouldSendRedirect()) { 
    $redirect_url = $auth_request->redirectURL(getTrustRoot(), 
               getReturnTo()); 

    // If the redirect URL can't be built, display an error 
    // message. 
    if (Auth_OpenID::isFailure($redirect_url)) { 
     displayError("Could not redirect to server: " . $redirect_url->message); 
    } else { 
     // Send redirect. 
     header("Location: ".$redirect_url); 
    } 
} else { 
    // Generate form markup and render it. 
    $form_id = 'openid_message'; 
    $form_html = $auth_request->htmlMarkup(getTrustRoot(), getReturnTo(), 
              false, array('id' => $form_id)); 

    // Display an error if the form markup couldn't be generated; 
    // otherwise, render the HTML. 
    if (Auth_OpenID::isFailure($form_html)) { 
     displayError("Could not redirect to server: " . $form_html->message); 
    } else { 
     print $form_html; 
    } 
} 
+0

Xem http://trac.openidenabled.com/trac/ticket/376. – crb

Trả lời

6

Động lực chính là, như Mark Brackett nói, các giới hạn về kích thước tải trọng được áp đặt bằng cách sử dụng chuyển hướng và GET. Một số triển khai đủ thông minh để chỉ sử dụng POST khi thông điệp vượt qua một kích thước nhất định, vì chắc chắn có những bất lợi đối với kỹ thuật POST. (Trưởng nhóm trong số đó là thực tế là nút Back của bạn không hoạt động.) Các triển khai khác, như mã ví dụ bạn trích dẫn, hãy đơn giản và nhất quán và bỏ qua điều kiện đó.

7

tôi có thể nghĩ đến một vài lý do:

  • Một chút của sự bảo mật bằng cách tối tăm - nó hơi nhiều việc phải làm xáo trộn đệ trình POST hơn GET
  • Caching và gửi lại quy định là hạn chế hơn cho POST hơn GET. Tôi không hoàn toàn chắc chắn điều này sẽ quan trọng đối với trường hợp sử dụng OpenID, mặc dù.
  • Bots sẽ không theo biểu mẫu POST, nhưng sẽ thực hiện theo chuyển hướng. Điều này có thể ảnh hưởng đến tải máy chủ.
  • Các trình duyệt khác nhau có độ dài tối đa khác nhau cho các yêu cầu GET - nhưng không có nào trong số chúng lớn bằng POST.
  • Một số trình duyệt sẽ cảnh báo về chuyển hướng đến một tên miền khác. Họ cũng sẽ cảnh báo nếu bạn đang gửi POST tới url không phải HTTPS.
  • Bằng cách tắt JavaScript, tôi có thể có trải nghiệm tương đối an toàn và không được chuyển hướng âm thầm sang miền khác.

Tôi không biết rằng bất kỳ lý do nào trong số này đều là lý do để chọn POST - trừ khi lượng dữ liệu được gửi vượt quá độ dài chuỗi truy vấn cho một số trình duyệt chính.

4

Phương pháp tương tự được sử dụng cho cấu hình SSO trình duyệt web SAML.Những động lực chính của việc sử dụng HTML bài viết chuyển hướng là:

  • dài Hầu như không giới hạn của tải trọng: trong SAML payload là một tài liệu XML ký với XMLDSig và mã hóa base64. Nó lớn hơn giới hạn 1024 ký tự thông thường của URL (một phương pháp hay nhất để hỗ trợ không chỉ bất kỳ trình duyệt nào nhưng các thiết bị mạng trung gian như Tường lửa, Reverse Proxy, Load Balancer).

  • Chuẩn W3C HTTP cho biết GET không có giá trị (cùng một URL GET được thực thi nhiều lần nên luôn dẫn đến phản hồi tương tự) và do đó có thể được lưu trong quá trình POST và không đạt được mục tiêu URL. Phản hồi của POST biểu mẫu HTML OpenID hoặc POST mẫu biểu mẫu SAML không được lưu trữ. Nó phải đạt được mục tiêu để bắt đầu phiên được xác thực.

Bạn có thể cho rằng việc sử dụng chuyển hướng HTTP GET cũng sẽ hoạt động vì truy vấn URL luôn thay đổi và bạn sẽ thực hiện đúng. Tuy nhiên, điều này sẽ là một giải pháp thay thế cho tiêu chuẩn W3C, và do đó, không nên là một tiêu chuẩn mà là một triển khai thay thế bất cứ khi nào cả hai đều đồng ý với nó.