2012-01-27 17 views
14

Tôi đang làm việc trên một công cụ dựa trên web để sắp xếp công việc chúng tôi làm tại văn phòng của mình. Các công cụ được cung cấp cho chúng tôi bởi đối tác của chúng tôi có thông tin đăng nhập chung mà toàn bộ sàn của chúng tôi sử dụng, nhưng cứ 30 phút một lần, điều này gây phiền toái khi phải đăng nhập lại cả ngày.

Điều tôi đã làm trước đây là tạo một iframe ẩn bên trong công cụ đăng nhập vào bằng cách gửi biểu mẫu ẩn trên trang tải và tiếp tục gửi biểu mẫu sau mỗi 30 phút để ngăn thời gian chờ. Sau đó, họ có thể gửi tìm kiếm đến công cụ đối tác trực tiếp từ công cụ của tôi (thông qua một công cụ khác, biểu mẫu hiển thị).

Tôi muốn sử dụng jQuery $.post() để cả hai thoát khỏi iframe ẩn và làm cho nó trở thành lần duy nhất để gửi thông tin đăng nhập là khi tìm kiếm được thực hiện. Bằng cách đó, nó không liên tục gửi yêu cầu khi không sử dụng, nhưng bạn vẫn có thể chạy tìm kiếm mà không phải lo lắng về thời gian đăng nhập. Có vẻ như chính sách xuất xứ cùng ajax đang ngăn chặn điều này, vì vậy tại thời điểm này tôi chỉ cần mở nó ra một cửa sổ mới có tên, và sau đó đệ trình hai biểu mẫu ẩn trong cửa sổ mục tiêu lần lượt đến cửa sổ mục tiêu kia.

Vấn đề với điều này là nếu yêu cầu đăng nhập không hoàn tất, yêu cầu tìm kiếm không được thực hiện và chúng sẽ được đưa đến trang đăng nhập một lần nữa. Nếu họ đóng cửa sổ và tìm kiếm lại nó sẽ làm việc, nhưng điều này cũng gây phiền nhiễu, chỉ cần không nhiều như tình hình ban đầu. Vì vậy, khác với thực tế là bạn thực sự phải xem trang mở ra (trừ khi nó nằm trong một khung nội tuyến ẩn) sự khác nhau giữa việc gửi các tham số thông qua $.post() và gửi biểu mẫu bằng cách sử dụng phương thức POST là gì? Họ trông giống hệt nhau trong firebug. Có cách nào tôi có thể thiết lập một cuộc gọi lại trong việc gửi biểu mẫu, vì vậy nó chờ yêu cầu đầu tiên hoàn thành trước khi bắt đầu lần thứ hai?

Trả lời

21

$ .post sử dụng xmlhttprequest để gửi dữ liệu. Xhr bị hạn chế thông qua cors. Gửi yêu cầu HTTP POST thẳng lên thì không.

+0

Tôi không thể đoán tại sao điều này lại bị bỏ phiếu. Có vẻ đúng với tôi. +1 –

+0

Đã xóa Downvote.Tôi nghĩ người dùng đã yêu cầu giải thích * tại sao * chỉ XHR có những hạn chế - đó là vấn đề nếu chủ đề là một câu hỏi đầy đủ khác với cơ thể và mọi người chỉ đọc kỹ chủ đề: p – ThiefMaster

+0

là cách để gửi thẳng Yêu cầu HTTP POST mà không thực sự mở trang? – sicks

-2

Chính sách gốc cùng nguồn gốc ajax là ngừng gửi thông tin của bạn qua mạng tới máy chủ cá nhân của họ mà không cần bạn biết điều đó xảy ra. Bài đăng trên trang tới các máy chủ khác không được đề xuất và có thể không thành công.

Bạn có thể giải quyết được không? Bạn có thể thay thế gửi biểu mẫu bằng jq để chờ trạng thái đăng nhập được hoàn thành và sau đó gửi biểu mẫu, tuy nhiên, tôi không chắc đây là một ý tưởng hay - vòng quay thường chỉ ra lỗi thiết kế.

Bạn có bao nhiêu quyền kiểm soát đối với mã? Bạn có thể thực hiện việc gửi làm một đăng nhập, và ngược lại gửi tìm kiếm? Hoặc thực hiện tìm kiếm không yêu cầu đăng nhập?

+0

Ngay bây giờ nó sẽ gửi đăng nhập, và sau đó tìm kiếm, nhưng không có cách nào để nói nếu yêu cầu đăng nhập đã hoàn thành trước khi thực hiện tìm kiếm. – sicks

+0

"Bài đăng trên trang đến các máy chủ khác không được khuyến nghị và có thể không thành công". metadaddy

15

Khi thực hiện yêu cầu POST đối với một tên miền khác, bạn sẽ không thể truy cập phản hồi bằng JavaScript (ngay cả khi bạn gửi biểu mẫu tới khung nội tuyến).

Tuy nhiên, khi sử dụng XHR, bạn có toàn quyền truy cập vào phản hồi, vì vậy bạn có thể làm nhiều điều xấu - ví dụ: truy cập các trang mà người dùng đăng nhập, tìm kiếm trong mạng nội bộ công ty của mình, v.v.

Vì vậy, các hạn chế XHR không phải để tránh CSRF mà tránh tiết lộ thông tin đặc quyền.

+0

Bạn có thể sao lưu điều đó không? Nếu tôi gửi yêu cầu đăng bài trong ứng dụng khách http thô (như curl), tôi có quyền truy cập vào phản hồi và tôi vẫn chưa thấy các cơ hội bạn mô tả. JavaScript sẽ có lợi thế như thế nào so với thư viện http có quyền truy cập vào nhiều tài nguyên hơn? Và điều gì sẽ xảy ra nếu tôi chỉ đơn giản sử dụng một trình duyệt không thực thi chính sách gốc giống nhau, được áp đặt ở cấp độ khách hàng, không phải máy chủ? – Anthony

+0

Khi sử dụng ứng dụng khách HTTP * bạn * bắt đầu yêu cầu và kiểm soát dữ liệu nào (ví dụ: cookie đăng nhập) bạn gửi. Nhưng bạn thường không có quyền kiểm soát JavaScript mà trang web sử dụng. Ví dụ, ở đây trên Stack Overflow một yêu cầu GET đơn giản là đủ cho tôi để xem thông tin đặc quyền chỉ có sẵn cho người kiểm duyệt. Bây giờ một trang web khác có thể (nếu nó không được phép thông qua tiêu đề x-frame-policy), hãy sử dụng iframe trỏ đến một URL chứa thông tin đó - nhưng nhờ có chính sách gốc, nó không có cách nào để truy cập dữ liệu trang. – ThiefMaster

+0

Có, nhưng đó là lý do tại sao chính sách gốc tương tự là tốt và phù hợp. Bạn đã chỉ ra rằng các bài viết biểu mẫu trên ajax dễ bị tổn thương hơn vì truy cập js để phản hồi việc đặt máy chủ có nguy cơ cao hơn bất kỳ tấn công xhr nào. Tôi nghĩ những gì bạn có nghĩa là chính sách gốc tương tự (nói chung và không cụ thể cho câu hỏi OP) bảo vệ máy chủ nhiều như người dùng. Một điểm hợp lệ, nhưng câu trả lời của bạn cho thấy nó là cụ thể để tạo thành các bài đăng, có thể gây hiểu lầm cho người đọc khi nghĩ rằng có một số cơ chế khác ở bên cạnh chính sách gốc. – Anthony

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