2011-08-23 22 views
7

Tôi có một câu hỏi đơn giản: Có thể sử dụng Digest-Authentication với XMLHTTPRequest không?Có thể sử dụng tính năng Digest-Authentication với XMLHTTPRequest không?

Nếu câu trả lời là không, lý do kỹ thuật là gì? Hoặc nếu có thể - làm thế nào tôi có thể làm điều đó?

Thanks a lot ... google không có câu trả lời tốt cho đến nay: -/

EDIT:

Cảm ơn câu trả lời. Sửa đổi tiêu đề để khớp với lược đồ xác thực thông báo, sau khi nhận được nonce, có vẻ như là một giải pháp.

Nhưng những gì tôi thực sự tìm kiếm là tôi có thể thay đổi cuộc gọi hiện tại của mình: xmlhttp.open ("GET", url, false, tên người dùng, mật khẩu); đến sth. như xmlhttp.open ("GET", url, sai, tên người dùng, mật khẩu, "DIGEST");

Đó cũng là một phần của câu hỏi ban đầu của tôi: Tại sao phương pháp mở không cung cấp tùy chọn thực hiện yêu cầu thông báo?

Có thể có js-lib có thể khuyên bạn nên làm điều đó - như bạn tưởng tượng tôi không thực sự muốn thay đổi một và đơn giản xmlhttp.open thành nhiều yêu cầu và đầu tiên nhận được nonce.

+0

Bạn đã thử những gì cho đến nay? Nếu trang máy chủ của bạn yêu cầu auth Digest (trả về 401 cho các yêu cầu chưa được xác thực) và bạn chuyển tên người dùng và mật khẩu vào cuộc gọi XHR open() của bạn, mọi thứ sẽ hoạt động tốt. – EricLaw

+0

Bạn đã thực hiện? Tôi sẽ thực sự apreciate một số mã. Cảm ơn! – vrunoa

Trả lời

8

Bạn có thể làm điều đó không thành vấn đề. Chỉ cần làm theo các phần của thông số kỹ thuật bạn cảm thấy thích;)
http://tools.ietf.org/html/rfc2617
và là tất cả những gì bạn thiếu để bắt đầu viết thư viện xác thực của mình
http://pajhome.org.uk/crypt/md5/
ở phía máy khách.

tên người dùng và mật khẩu trước khi trao đổi
Hey Tôi muốn xác thực ----> Máy chủ
Ok đây là một nonce/muối ----> client
đây là một md5 hash sum của tên người dùng của tôi dấu thời gian mật khẩu và muối -----> máy chủ
Tôi vừa tạo mật khẩu và tên người dùng giống như cách bạn đã làm và chúng giống nhau -----> khách hàng
Đó là những điều cơ bản về nó.

Tôi đã bỏ qua rằng bạn cần bao gồm URI của tài nguyên được yêu cầu trong hashsum !!!!
Tất nhiên bạn làm điều này với mọi yêu cầu bạn thực hiện cho một tài nguyên cho máy chủ theo cách mà một số người chặn mã băm chỉ có thể xem nội dung bạn yêu cầu và không thể yêu cầu tài nguyên linh tinh.Phương thức này không bảo mật dữ liệu chỉ cần truy cập vào nó.

+0

Tôi không đồng ý. Bất cứ ai cũng có thể yêu cầu một nonce đến máy chủ. Làm thế nào để bạn muốn vận chuyển an toàn đến phía khách hàng? – Chielus

+5

Bạn không chỉ làm cho việc tìm ra mật khẩu của mình từ md5 trở nên khó khăn hơn và làm cho mỗi lần xác thực trở nên độc đáo. http://en.wikipedia.org/wiki/Cryptographic_nonce. Bằng cách này một số người không thể ở giữa bạn băm và xác thực lại với nó tại một thời điểm khác. Trong thực tế, họ sử dụng một nonce trong Oauth. Tôi biết những gì bạn đang nghĩ rằng vẫn còn hoàn toàn không an toàn nhưng mục đích của loại xác thực này chỉ là để bảo vệ tên người dùng và mật khẩu của bạn. Nó rất cơ bản. – Prospero

+0

:/Cuộc bỏ phiếu xuống là gì? – Prospero

0

Cách tốt nhất để làm điều này là sử dụng SSL. Tôi không nghĩ rằng bất kỳ giải pháp an toàn nào khác tồn tại (sửa tôi nếu tôi sai)

+1

Không sai chỉ thận trọng;) – Prospero

+1

Thông báo an toàn hơn SSL cơ bản +! Kiểm tra RFC 2617, phần về bảo mật. – wprl

+1

Không có SSL, kẻ tấn công MitM (ví dụ: proxy thù địch hoặc bị xâm phạm; nói tại điểm truy cập WiFi công cộng) có thể tiêm JavaScript tùy ý (hoặc chỉ đơn giản là liên kết) vào HTML. Bằng cách này, các yêu cầu của kẻ tấn công sẽ bắt nguồn từ trình duyệt của người dùng, do đó máy chủ sẽ không có bất kỳ cơ hội nào để nói rằng đây là những _not_ từ người dùng. Kẻ tấn công thậm chí không cần phải tìm ra mật khẩu. – robert4

6

Hãy xem bài viết này: http://marcin-michalski.pl/2012/11/01/javascript-digest-authentication-restful-webservice-spring-security-javascript-ajax/. Nó giải thích cách làm JavaScript client cho Digest Authentication với SpringSecurity ở phía máy chủ. Mã này có sẵn trong github: https://github.com/Arrowgroup/JSDigestAuth

+0

Đây là câu trả lời hay nhất. Chỉ vào bài đăng của ai đó đã thực hiện tất cả công việc và nó cung cấp mã nguồn đầy đủ (với một cách rất dễ dàng để kiểm tra nó) –

3

Tôi đã mã hóa toàn bộ quy trình làm việc này, không khó chút nào khi bạn đang sử dụng thư viện bên ngoài cho MD5 (Tôi sử dụng Crypto-js).

Vấn đề lớn nhất bạn có thể có là trên máy chủ đầu tiên 401 trả lời bất kỳ trình duyệt nào được sử dụng nhiều nhất sẽ mở hộp thoại để nhận thông tin đăng nhập của bạn.Theo như tôi đã thấy không có cách nào dễ dàng để vượt qua điều này: How can I supress the browser's authentication dialog?

Để giải quyết, tôi đã sửa đổi máy chủ web mà tôi đã mã hóa từ một dự án mã hóa C#. Trên yêu cầu đầu tiên, khách hàng chuyển tiêu đề "Cảnh báo" cho biết "Không tăng 401". Máy chủ tạo ra thử thách và gửi lại với một HttpException tùy chỉnh, không 401 (tôi sử dụng 406 cho thời điểm này, "không được chấp nhận" trong HTTP). Máy khách tạo băm và gửi lại.

Tôi có thể đăng một số đoạn mã nếu có ai quan tâm, đây là một câu hỏi cũ.

+0

Điều này dường như không đúng với Safari, khi nó nhận 401 trên XHR. – wprl

+0

Ý của bạn là gì? "this" = "trình duyệt cũng mở hộp thoại cho XHR 401"? Nếu đúng như vậy, bạn không cần phải sử dụng mẹo tiêu đề cảnh báo. Các giải pháp tương thích rộng rãi vẫn sẽ yêu cầu giải pháp. – malber

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