2011-12-23 72 views
9

Tôi có khoảng 100 trang web được mã hóa bằng ASP cổ điển. Mỗi trang web chấp nhận đơn đặt hàng và lưu trữ chúng trong cơ sở dữ liệu. Tuy nhiên, việc thanh toán các đơn đặt hàng này phải được thực hiện trên một trang web khác, cũng được mã hóa bằng ASP cổ điển. Tất cả các trang web đều thuộc sở hữu của cùng một công ty, được lưu trữ trên cùng một máy chủ IIS và sử dụng cùng một cơ sở dữ liệu SQL Server.Tự động đăng nhập vào trang web hiện tại nếu người dùng đăng nhập vào một trang web khác

Bây giờ, người dùng đăng ký bằng cách nhập một số thông tin cá nhân và nhật ký vào một trong các trang web này (ví dụ: website-for-newjersey.com) và đặt hàng. Sau đó, anh ta được chuyển đến trang web thanh toán (payments.master-website.com trên https), nơi một số thông tin cá nhân của anh ấy (địa chỉ, thành phố, tiểu bang để giao hàng; tên của chủ sở hữu thẻ tín dụng, v.v.) xuất hiện trên biểu mẫu thanh toán. Thông tin cụ thể về thẻ tín dụng được nhập trên trang đó.

Do độ nhạy của thông tin được hiển thị trên trang đó, người dùng phải đăng nhập vào trang web thanh toán trước khi họ có thể xem biểu mẫu thanh toán được điền sẵn. Và tôi không muốn người dùng đăng nhập hai lần (một lần trên mỗi trang web). Có cách kiểm tra đáng tin cậy không nếu người dùng đăng nhập vào trang web giới thiệu trang web bằng ASP cổ điển.


câu chuyện dài ngắn

  • Trên trang web BI cần phải kiểm tra nếu người truy cập đăng nhập vào trang web Một
  • Trên trang web BI cần biến session ID từ website Một
  • Cả các trang web sử dụng cùng một máy chủ cơ sở dữ liệu
  • Tôi cần hướng dẫn rõ ràng
  • Giải pháp PHP hoặc ASP.NET có thể chấp nhận được nếu nó là chung/di động
+2

tại sao bạn không đi với đề xuất roberts? đó là một cách tiếp cận tuyệt vời và bạn không thể chia sẻ phiên giữa các miền khác nhau, nếu không bạn sẽ có thể ăn cắp phiên facebook hoặc ai đó. Bất cứ khi nào bạn sắp trả tiền, hãy làm như robert nói. lưu trữ một chuỗi ngẫu nhiên trong cơ sở dữ liệu của bạn liên quan đến người dùng đó. Mã hóa nó, chuyển qua SSL tới trang web mới của bạn, giải mã và kiểm tra người dùng trong cơ sở dữ liệu. Ngoài ra kiểm tra với thời gian (như trong vòng 1-2 phút sau khi tạo) – Muqito

+1

Bạn đã nghe nói về một cái gì đó gọi là cầu nối phiên? – TechGirl

+0

@TechGirl: không, tôi không có. –

Trả lời

9

Từ trang gọi điện, bạn có thể tạo một guid hoặc một số giá trị được tạo ngẫu nhiên khác. Lưu trữ nó trên hồ sơ người dùng (thiết lập hết hạn trong một khoảng thời gian xác định) trong cơ sở dữ liệu, mã hóa nó và chuyển nó qua SSL tới trang thanh toán nơi nó được giải mã và sau đó so sánh với cơ sở dữ liệu. Nếu chúng khớp nhau thì người dùng đã đăng nhập, nếu không khớp thì họ được yêu cầu đăng nhập.

Một cách khác mặc dù tôi không chắc chắn rằng nó có thể được thực hiện với các tên miền khác nhau đang sử dụng phiên. Vì tất cả chúng đều trên cùng một máy nên có thể nhưng tôi không chắc chắn 100% trên máy đó.

+0

Phiên hết hạn khi nhấn tên miền khác, ngay cả tên miền phụ. – TheCarver

+0

Tác phẩm này hoạt động. Tuy nhiên, điều gì sẽ xảy ra nếu ai đó sao chép mã thông báo hợp pháp (và được mã hóa) từ trang web A, mở trang web B trong trình duyệt/máy tính khác và đăng mã thông báo (mã hóa)? –

+1

Bạn có thể sử dụng một số thông tin máy tính/trình duyệt trong giá trị được mã hóa sau đó khi giải mã, bạn xác thực rằng người đó vẫn còn trên cùng một máy. Đăng nó qua SSL nên có một lớp mã hóa. – Robert

4

Điều bạn hỏi được gọi là đăng nhập một lần (SSO) và có thể được triển khai theo nhiều cách. Có nhiều chủ đề về vấn đề này, ví dụ: What's your favorite cross domain cookie sharing approach? nhưng tất cả chúng đều thay đổi tùy theo yêu cầu riêng lẻ.

Trong trường hợp bạn có các miền khác nhau (vì vậy bạn không thể chia sẻ cookie trên chúng), bạn trộn http và https (có thể là một vấn đề) và bạn có nhiều ứng dụng, do đó bạn sẽ không thực hiện nhiều thay đổi.

Vì vậy, tôi muốn giới thiệu để xem xét đề nghị của Robert:

  1. Khi người dùng được xác thực cho lần đầu tiên (trang web A) giúp bạn tiết kiệm một GUID trong cơ sở dữ liệu. Thêm một bảng mới cho các phiên với các cột cho GUID, userid, ip và dấu thời gian hoặc lưu nó như là một phần của dữ liệu đơn đặt hàng. Lưu trữ GUID trong đối tượng phiên.
  2. Trên trang có liên kết đến trang thanh toán đặt nó trong chuỗi truy vấn hoặc dưới dạng biến ẩn (nếu đó là biểu mẫu).
  3. Trên tên miền khác (trang web B) kiểm tra GUID và sau đó tra cứu nó trong cơ sở dữ liệu. Nếu nó không quá cũ sau đó xác thực người dùng, nếu không chuyển hướng anh ta đến một trang đăng nhập.

Nếu bạn không thể thay đổi liên kết đến trang thanh toán thì bạn có thể thử bỏ qua bước 2 và xác thực người dùng bằng IP của mình nhưng điều này có thể quá nguy hiểm.

+0

Điều này có vẻ đơn giản. Tuy nhiên, điều gì sẽ xảy ra nếu ai đó sao chép mã thông báo hợp lệ từ trang web A, mở trang web B trong trình duyệt/máy tính khác và đăng mã thông báo? –

+0

Một sự kết hợp của (xác nhận IP + kiểm tra referer + sử dụng POST) nên làm điều đó. Bạn cũng có thể loại bỏ GUID khỏi cơ sở dữ liệu khi người dùng đã được xác nhận để không thể sử dụng lại cùng một GUID (url) nữa. – Alex

+1

@SalmanA: bạn không lưu GUID. Thay vào đó bạn lưu * và cập nhật * a * UUID ngẫu nhiên * được tạo mỗi lần bởi trang nguồn khi chuyển hướng. Sau đó, bạn thanh lọc UUID từ DB khi nhận được nó trên trang đích. Điều này có nghĩa là người dùng tinh nghịch của bạn sẽ phải * chặn * chuyển hướng của chính mình (nếu không UUID sẽ bị hủy kích hoạt), ** và ** phải sao chép và đăng GUID từ một máy tính khác trong vòng 5 giây. Chuyển hướng 302 bình thường không mất nhiều thời gian, vì vậy tất cả UUID cũ hơn một vài giây có thể được coi là không hợp lệ một cách an toàn. – LSerni

1

Xác thực dựa trên cổng truyền là một dịch vụ xác thực tập trung do Microsoft cung cấp cung cấp dịch vụ đăng nhập và dịch vụ hồ sơ lõi cho các trang thành viên. Để biết thêm thông tin, xem Web site của Microsoft sau đây:

Passport Authentication Provider

+0

Xác thực hộ chiếu đã lỗi thời và đã bị thay thế bằng Live ID. Nó sẽ yêu cầu một tài khoản Live ID khác với những gì được hỏi ở đây. – Alex

1

Nếu bạn không thể thực hiện một Single Sign-On ở cấp cơ sở hạ tầng của bạn, bạn nên sử dụng Identity Federation cho phép các ứng dụng của bên thứ đáng tin cậy khác nhau để chia sẻ xác thực thông qua xác nhận quyền sở hữu.

Điều này có thể được thực hiện bằng Security Assertion Markup Language (SAML) trực tiếp hoặc với các sản phẩm/tiêu chuẩn như:

Ngoài ra bạn có thể có một cái nhìn tại OAuth hoặc OpenID đó là các lược đồ xác thực được chia sẻ nhiều hơn SSO hoặc liên kết danh tính.

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