2010-05-07 25 views
11

Nền: Chúng tôi đang trong quá trình viết trang đăng ký/thanh toán và triết lý của chúng tôi là mã hóa tất cả xác thực và kiểm tra lỗi ở phía máy chủ trước, sau đó thêm khách hàng bên xác nhận là bước thứ hai (un-obstructive jQuery).Hành vi của bài đăng biểu mẫu có thay đổi trong các trình duyệt hiện đại không? (hoặc số nhấp chuột được xử lý bởi trình duyệt)

Chúng tôi muốn vô hiệu hóa phía máy chủ nhấp đúp, vì vậy, chúng tôi đã viết một số mã khóa an toàn, chủ đề để xử lý các bài viết/điều kiện chủng tộc đồng thời. Khi chúng tôi cố gắng kiểm tra điều này, chúng tôi nhận ra rằng chúng tôi không thể gây ra một tình huống hoặc tình trạng chủng tộc đồng thời xảy ra.

Tôi nghĩ rằng (trong trình duyệt cũ hơn anyway) double click chuột vào nút gửi làm việc như sau:

  • tài nhấp chuột đúp nút gửi.
  • Trình duyệt gửi một bài đăng trên nhấp chuột đầu tiên
  • Khi nhấp lần thứ hai, trình duyệt sẽ hủy/bỏ qua bài đăng ban đầu và khởi tạo bài đăng thứ hai (trước khi bài đăng đầu tiên trả về).
  • Trình duyệt chờ bài đăng thứ hai trở lại, bỏ qua phản hồi bài đăng ban đầu.

Tôi nghĩ rằng từ phía máy chủ nó trông như thế này: Máy chủ được hai bài yêu cầu đồng thời, thực hiện và đáp ứng cho họ cả (không biết rằng không ai được nghe câu trả lời đầu tiên).

Từ thử nghiệm của chúng tôi (FireFox 3.0, IE 8.0) đây là những gì thực sự xảy ra:

  • tài nhấp chuột đúp nút gửi
  • trình duyệt sẽ gửi một bài cho các nhấp chuột đầu tiên
  • trình duyệt xếp hàng lên lần nhấp thứ hai, nhưng chờ phản hồi từ lần nhấp đầu tiên.
  • Trả về phản hồi từ lần nhấp đầu tiên (phản hồi bị bỏ qua?).
  • Trình duyệt gửi một bài đăng cho lần nhấp thứ hai.

Vì vậy, từ phía máy chủ: Máy chủ nhận được một bài đăng mà nó thực hiện và trả lời. Sau đó, máy chủ sẽ nhận được yêu cầu thứ hai mà nó thực thi và trả lời.

Câu hỏi của tôi là, điều này luôn luôn hoạt động theo cách này (và tôi đang mất trí)? Hoặc đây có phải là một tính năng mới trong các trình duyệt hiện đại để ngăn các bài viết đồng thời được gửi đến máy chủ không?

Dường như đối với phòng ngừa nhấp đúp vào phía máy chủ, chúng tôi không phải lo lắng về các bài đăng đồng thời hoặc điều kiện chủng tộc. Chỉ cần lo lắng về việc xếp hàng các bài đăng.

Cảm ơn bạn trước vì đã gửi phản hồi/nhận xét.

Alex

+1

+1 Câu hỏi rất rõ ràng và thật thú vị khi xem sơ đồ hành động của người dùng. Tôi không chắc chắn về câu trả lời, nhưng mọi thứ nói chung * có * được tiến hành thay vì tôn vinh một cú nhấp chuột hơn hai lần - nhấp đúp là mô hình cũ hơn, làm trung tâm trên máy tính để bàn. –

+0

Cập nhật: Hành vi có vẻ khác với IE8 (cho phép nhiều bài đăng đồng thời tới máy chủ) và FF/Chrome (xếp hàng nhiều lần nhấp). Tôi sẽ đăng nhiều phát hiện hơn khi chúng tôi thử nghiệm nhiều hơn. –

Trả lời

0

Chừng nào yêu cầu là trong việc kết nối hoặc gửi sân khấu, nhấp vào trình trong việc nộp đầu tiên hủy bỏ yêu cầu, bắt đầu một cái mới mà không cần máy chủ 'biết'.

+0

Điều này có vẻ là trường hợp với IE8, nhưng không phải với Chrome hoặc FireFox. –

1

điều này có thể là câu trả lời ngu ngốc, nhưng tại sao bạn không tắt nút gửi bằng javascript khi nhấp, vì vậy bạn không phải lo lắng về nhiều lần nhấp. tôi thường làm điều này trên hầu hết các hình thức tôi thực hiện và có vẻ như để giải quyết vấn đề.

bạn đã nói bạn đang sử dụng javascript để không phải vấn đề phải không?

+0

Chiến lược đầu tiên là thực hiện tất cả xác thực/kiểm tra ở phía máy chủ. Khi đã xong, chúng tôi sẽ thực hiện kiểm tra bên ứng dụng khách. Điều này đảm bảo rằng ngay cả khi ai đó vô hiệu hóa JavaScript của họ hoặc lỗi phía máy khách xảy ra, ứng dụng đó sẽ vẫn hoạt động bình thường. Tôi đồng ý, giải pháp phía khách hàng gần như là tầm thường, nhưng chúng tôi muốn đảm bảo ứng dụng của chúng tôi cũng vững chắc ở phía máy chủ. –

3

Tình huống tương tự mà bạn cần xử lý (giải pháp javascript vô hiệu hóa-gửi-nút không bao gồm) là nơi người dùng nhấp vào Gửi, máy chủ xử lý yêu cầu, nhưng trong khi xử lý kết nối internet của người dùng đi xuống (có lẽ họ đang trên một chuyến tàu đi vào một đường hầm).

Khi tàu ra khỏi đường hầm, người dùng không biết giao dịch của họ có thành công hay không - họ nhấn nút, nhưng không có gì thay đổi trên trang (hoặc có thể họ có trang "Thử lại"). Điều tự nhiên để họ làm là nhấp vào Gửi lại (hoặc nút "Thử lại").

Cách tốt nhất để xử lý trường hợp này là bao gồm id giao dịch duy nhất trong biểu mẫu (trong trường ẩn). Tạo ra id này ngẫu nhiên, và khi một giao dịch được xử lý thành công, lưu trữ nó trong cơ sở dữ liệu trong danh sách các giao dịch đã hoàn thành.

Sau đó, khi bạn nhận được POST, hãy kiểm tra xem giao dịch này đã được xem chưa - và nếu có, hãy chuyển thẳng đến trang trạng thái. Khoảng: (! Miễn là bạn có một cơ sở dữ liệu đúng cách hỗ trợ giao dịch - và kể từ khi bạn đang xử lý thanh toán tôi hy vọng bạn làm)

BEGIN TRANSACTION 

SELECT * 
FROM completedTransactions 
WHERE userId = ... AND transactionId = ... 

<if we got a result - display results of previous transaction> 

<otherwise - process the request as normal> 

INSERT INTO completedTransactions (userId, transactionId) 
VALUES (....) 

END TRANSACTION 

này có ưu điểm là bạn không cần phải làm bất cứ loại ren hoặc khóa - mọi thứ "chỉ làm việc".

(mặc dù cẩn thận - một số hệ thống cơ sở dữ liệu tùy tiện có thể hủy bỏ giao dịch của bạn nếu có một vấn đề đồng thời - nhưng điều này (hiếm) tình hình có thể dễ dàng xử lý với việc sử dụng một vòng lặp retry ...)

Như để thử nghiệm kép nhấp chuột từ trình duyệt: nó có tạo nên sự khác biệt nào không nếu bạn nhấn nút "dừng" giữa hai lần nhấp "gửi"?

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