Hiểu quản lý phiên và xác thực người dùng của Drupal


16

Tôi có một yêu cầu trong đó, tôi phải thay thế xác thực người dùng mặc định bằng xác thực của máy chủ trung tâm tức là máy chủ SSO.
Bằng cách gỡ lỗi Drupal tôi đã biết rằng tất cả quản lý phiên xảy ra trong includes/session.inctệp. Tôi muốn thực hiện xác thực như trong hình:

chụp nhanh

SCENARIO: Đăng nhập
Chi tiết các bước sẽ là:

  1. Thay thế biểu mẫu đăng nhập để gửi tên người dùng và mật khẩu đến máy chủ SSO ( không phải trên Drupal , mà trên .NET).
  2. Xác thực người dùng trên máy chủ SSO bằng cơ sở dữ liệu của trang web đó; và gửi phản hồi trở lại một số trang PHP tùy chỉnh trên trang web của tôi (hoặc một mẫu bằng mô-đun?).
  3. Sử dụng phản hồi, xác định người dùng trong bảng người dùng và tạo phiên cho người dùng đó mà không cần kiểm tra mật khẩu (vì điều đó có nghĩa là xác thực kép). Theo mặc định, Drupal đặt cookie với tên của $insecure_session_namebiến và có giá trị $sid. Tôi muốn Drupal không đặt cookie ở đây, thay vào đó hãy gửi các giá trị của biến đến máy chủ SSO.
  4. Máy chủ SSO sẽ lấy các giá trị, tạo cookie và thả nó vào miền chính domain.com(để nhắc cả hai my websitesso servernằm trên tên miền phụ của tên miền chính, cũng không thuộc Drupal). Sau đó, trang web drupal có thể đăng nhập bằng cách sử dụng cookie đó.

Tôi biết đó là một câu hỏi khó, tôi chỉ tìm kiếm con trỏ là tôi nên bắt đầu như thế nào? như họ nói "bạn không nên hack lõi". Vì vậy, câu hỏi của tôi là:

  1. Tôi nên tìm ở đâu để hiểu cách thức xác thực Drupal và quản lý phiên hoạt động theo chiều sâu?
  2. Có cách nào để tôi có thể gọi các hàm trong includes/session.incviệc sử dụng hook (như các bình luận với các hàm nói "chỉ sử dụng nội bộ / không được sửa đổi") không?

LƯU Ý: Tôi sẽ sử dụng cùng một phương pháp để đăng ký người dùng, để bản ghi vẫn nằm trong cơ sở dữ liệu trung tâm của máy chủ SSO. Và trong thời gian đó sẽ đưa vào một số mật khẩu rác cho cùng một người dùng trong cơ sở dữ liệu của trang web Drupal (vì mật khẩu sẽ không được kiểm tra trong khi đăng nhập).


Bạn có cần SSO thật (đăng nhập vào một trang và bạn đã đăng nhập vào tất cả các trang), hoặc chỉ xác thực với hệ thống bên ngoài?
mpdon Arena

@MPD Tôi muốn có một SSO thực sự, sẽ yêu cầu đăng nhập vào một trang web và -> xác thực cùng một người dùng trên tất cả các trang web (có thể không có trên Drupal.
AjitS

@AjitS nếu bạn đã thực hiện thành công điều này, bạn có thể vui lòng đặt câu trả lời chi tiết. Tôi đang sử dụng user_login_finalize nhưng tôi được thông báo do vấn đề GDPR tôi không thể lưu trữ các chi tiết trong Drupal.
Jignesh Rawal

Câu trả lời:


17

Drupal hỗ trợ xác thực bên ngoài . Có nhiều mô-đun xác thực thay thế cho Drupal, chẳng hạn như OpenID (bao gồm trong lõi), Trình kết nối OAuth hoặc LDAP . Tìm hiểu thêm về cách xác thực Drupal hoạt động; tốt nhất là xem xét các mô-đun OpenID và OAuth, và để hình thức đăng nhập cốt lõi gửi gọi lại. Nhưng, AFAIK, họ luôn bắt đầu phiên Drupal bình thường sau khi xác thực thành công.

Để quản lý phiên, Drupal cắm vào xử lý phiên PHP và đăng ký trình xử lý riêng. Phần cuối phiên Drupal có thể cắm được, bạn có thể đặt session_incbiến thành đường dẫn của tệp cung cấp các triển khai thay thế của các hàm được tìm thấy trong includes/session.inc. Các memcache mô-đun sử dụng để lưu trữ phiên trong memcached.

Đối với tài liệu tham khảo, OpenID mô-đun xử lý xác thực thành công trong việc openid_authentication()mà bản thân ceats và gọi biểu mẫu đăng nhập người sử dụng gửi handler (ví dụ. user_login_submit()). Trình xử lý trình này tự nó rất đơn giản, nó tải người dùng được xác thực thành công user_load()vào $userbiến toàn cục, sau đó gọi hàm user_login_finalize()nào xử lý phiên, dấu thời gian đăng nhập trong userbảng và gọi hook_user_login()thực hiện.

Một lựa chọn khác là sử dụng user_external_login_register()chức năng. Hàm này sẽ đăng nhập một người dùng bên ngoài. Nó cũng tạo một người dùng cục bộ nếu cần. Nếu bạn cần kiểm soát nhiều hơn vào việc tạo ra người dùng cục bộ, bạn luôn có thể sử dụng user_save(), user_set_authmaps(), user_login_submit()user_external_load()từ bạn tùy chỉnh gọi, sử dụng user_external_login_register()như mẫu của những gì cần phải được thực hiện.


2
Đây là vị trí khá nhiều trên. Phía Drupal đăng nhập người dùng bên ngoài cực kỳ dễ dàng. Việc nâng vật nặng (nếu có) thực sự đang giao tiếp với hệ thống bên ngoài.
mpdon Arena

@MPD Tìm kiếm điều ngược lại, trong trường hợp cụ thể của tôi. Hệ thống bên ngoài = dịch vụ web JSON = công cụ tương đối dễ dàng. Hành vi Drupal = thay đổi không thể đoán trước từ phiên bản sang phiên bản = khó khăn như địa ngục và không có chẩn đoán hữu ích khi mọi thứ bị phá vỡ.
Trejkaz

1

user_authenticate () APi có thể có ích ở đây.

3.Sử dụng phản hồi, xác định người dùng trong bảng người dùng và tạo phiên cho người dùng đó mà không cần kiểm tra mật khẩu (vì điều đó có nghĩa là xác thực kép). Theo mặc định, Drupal đặt cookie với tên của $insecure_session_namebiến và có giá trị $sid. Tôi muốn Drupal không đặt cookie ở đây, thay vào đó hãy gửi các giá trị của biến đến máy chủ SSO.

EDIT: Khi máy chủ SSO trở lại với sử dụng đúng API này để đăng nhập người dùng sẽ tự động chăm sóc các phiên cho bạn. Tôi nghĩ sẽ tốt hơn nếu bạn sử dụng user_authenticate()thay vì tự tạo phiên. Nó không nên tạo ra vấn đề ngay cả khi xác thực kép miễn là p-assowrd hợp lệ được cung cấp.

Không chắc chắn về 4. Bạn có muốn hiển thị cookie trong cả hai miền không? Nếu vậy thì trong settings.php khởi tạo $cookie_domaintên miền. Sau đó, cookie trong trang con sẽ có sẵn trong trang web mẹ.


cảm ơn bạn đã phản hồi Tôi không thể sử dụng user_authenticatevì, việc xác thực không cần phải xảy ra trên trang web Drupal. Tôi có thể tạo phiên bằng cách gọi drupal_session_generate()drupal_session_regenerate()từ tệp session.inc. Bạn đã hiểu đúng về yêu cầu cho cookie .. vui lòng xem chỉnh sửa.
AjitS

@indrock Kiểm tra liên kết đó. User_authenticate sẽ cho phép bạn đăng nhập tên người dùng và mật khẩu được cung cấp là chính xác. Ở Bước 3 khi bạn xác minh rằng tên người dùng và thẻ là chính xác trên máy chủ SSO, sau đó sử dụng API này để đăng nhập người dùng. Nhưng bạn nên có mật khẩu được lưu trữ trên Drupal. Làm điều này sẽ làm cho nó dễ dàng hơn nhiều so với hack lõi.
GoodSp33d
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.