Có thể phát triển + Omniauth có một số loại đăng nhập không?

Question

Tôi đã sử dụng Devise làm đá quý xác thực tiêu chuẩn cho các dự án khác. Trong một dự án khác, tôi đã sử dụng Devise + Omniauth để xác thực Twitter.

Trong một dự án mới, tôi cần người dùng cuối của mình có thể đăng nhập qua Twitter và Facebook hoặc để có thể đăng ký qua ứng dụng. Trong tương lai, người dùng có thể liên kết các tài khoản của mình với nhau. Ví dụ, tài khoản Twitter và Facebook của anh ấy. Hoặc, tài khoản Twitter và "gốc" của anh ấy. "Gốc" là tài khoản anh đăng ký trực tiếp với ứng dụng web.

Devise có khả năng như vậy không? Nếu vậy, làm cách nào để chúng tôi liên kết các tài khoản của người dùng với nhau? Khái niệm đằng sau điều này là gì? Làm cách nào để ứng dụng biết được tài khoản Facebook và Twitter nào thuộc về người dùng nào?

Ý tưởng và đề xuất được chào đón.

EDIT:

Tôi đã làm theo http://railscasts.com/episodes/236-omniauth-part-2?autoplay=true và những gì tôi không nhận được. Nếu

1. người dùng được đăng xuất khỏi ứng dụng,
2. người dùng có một tài khoản đăng ký với ứng dụng,
3. người dùng đăng nhập với một nhà cung cấp dịch vụ khác nhau (facebook, twitter, vv).

Ứng dụng biết cách liên kết nhà cung cấp dịch vụ mới với tài khoản hiện có của anh ấy?

Stackoverflow.com có ​​tính năng này. Nhưng một nhà cung cấp dịch vụ mà họ không bao gồm trong "đa dấu" của họ về tính năng là Twitter. Tôi đoán đó là vì Twitter không tiết lộ email của người dùng thông qua API của họ. Trong khi các nhà cung cấp dịch vụ khác (Facebook, Yahoo, Gmail) thực hiện.

Answer 1

Email thường được sử dụng để liên kết tất cả các tài khoản, nhưng với Twitter, bạn không thể nhận được tài khoản email. Sử dụng email không thực sự là một thực tiễn tốt vì người dùng không nhất thiết phải đăng ký từng dịch vụ với cùng địa chỉ email.

Hỏi người dùng nếu anh ta muốn sử dụng facebook/twitter/google/openid để xác thực khi anh ấy đăng nhập là cách dễ nhất và người dùng có thể dự đoán được nhiều hơn. Bạn phải ngăn chặn hiệu quả "trang web này biết tài khoản facebook của tôi như thế nào? Tại sao họ theo dõi tôi?"

Như một lưu ý phụ, phần khó nhất là không thêm phương thức xác thực mới, nhưng hợp nhất các tài khoản nếu người dùng, ví dụ, tạo một tài khoản với facebook và một tài khoản với twitter.

Answer 2

Hãy tìm kiếm Screencasts này, nó sẽ giúp bạn: OmniAuth

và OmniAuth part2

Gần đây I'he chơi với vấn đề chẳng hạn như bạn có bây giờ. Mục tiêu của tôi là triển khai nhiều giải pháp xác thực: Google, Twitter, Facebook .. cùng một lúc - vì vậy người dùng có thể đăng nhập với nhiều nhà cung cấp (như trong Stackoverflow.com) và sau khi đăng xuất, anh ấy vẫn đăng nhập bằng một dịch vụ khác. Tôi đã thực hiện điều này bằng cách tạo ra sơ đồ sau (tôi không có mã của tôi ngay bây giờ nhưng nó sẽ cho bạn một đầu mối):

class User 
has_many :authentications 
has_many :known_authentications 
end 

class Authentication 
    #implemented nearly as in Ryan's Railscasts (It keeps authorization info) 
end 

class KnownAuthentications 
    #has :provider, :user_id, :uid and :email columns. Here I keep all authorizations for registered user, that he ever had(so I can verify user by email and guess that this is the same user as logged in from different services). I fill this table when user registers with any service(Google, Twitter etc.). 
end 

Khi logges người dùng trong tôi kiểm tra bảng KnownAuthentifications cho dịch vụ ủy quyền hiện tại bằng cách email (dịch vụ OpenID vượt qua email với các thông số khác, OAuth - không (vì vậy ở đây tôi tạo email giả mạo, giả mạo fake@email.com -> vì vậy Devise không thông qua ngoại trừ)). Bây giờ tôi biết rằng người dùng đã đăng nhập từ Google giống như hiện đã đăng nhập từ Twitter.

Answer 3

lập mưu là hoàn toàn có khả năng đó, nhưng vì mỗi nhà cung cấp có dấu hiệu riêng của mình bạn cần một cách để nhận ra người dùng không vấn đề mà nhà cung cấp ông chọn để đăng nhập.

Cách phổ biến nhất để làm điều đó bằng cách sử dụng trường email, bạn cần yêu cầu email trong mỗi yêu cầu của nhà cung cấp, cá nhân tôi không thích nó vì người dùng vẫn có thể có các email khác nhau trong các nhà cung cấp khác nhau.

Để khắc phục điều này, bạn có thể cung cấp tùy chọn "kết nối đăng nhập Facebook với thông tin đăng nhập Twitter của tôi".

Answer 4

Tôi có cùng một câu hỏi này và mặc dù đây không phải là giải pháp hoàn chỉnh (tôi không nghĩ rằng thực sự là 100% không có tính cách), đây là những gì tôi đang xây dựng ngay bây giờ.

Ví dụ: Trang web có tên người dùng/mật khẩu, Facebook và Twitter để xác thực.

Một người dùng truy cập trang web và muốn đăng ký. Họ đăng ký sử dụng Twitter để xác thực. Twitter chuyển một loạt thông tin ngoại trừ địa chỉ email. Tôi đang lưu trữ thông tin hồ sơ (vị trí, tên, vv) mà tôi nghĩ rằng sẽ hữu ích để so sánh. Người dùng được trình bày với một trang hồ sơ ngay lập tức sau khi xác thực để xác minh thông tin hồ sơ (họ có thể loại bỏ bất kỳ thông tin nào họ không muốn lưu trữ). Họ cũng có cơ hội thêm các phương thức xác thực bổ sung (trong trường hợp này là username/password và Facebook). Bạn càng khuyến khích họ liên kết các phương thức xác thực bổ sung trong khi đăng nhập ít rắc rối hơn bạn sẽ có với các tài khoản trùng lặp. Tuy nhiên nó vẫn tồn tại như một trường hợp cạnh.

Kịch bản trường hợp cạnh như sau: người dùng đăng ký với Twitter rồi ngay lập tức đăng xuất và cố gắng đăng nhập bằng Facebook. Phương thức đăng nhập phát hiện rằng đây là xác thực mới và do đó, nó so sánh dữ liệu oauth từ Facebook với thông tin tiểu sử hiện có và cố gắng tìm các kết quả phù hợp. Sau đó tôi hiển thị 10 kết quả phù hợp hàng đầu và yêu cầu người dùng xác minh xem họ có tồn tại không để tài khoản có thể được liên kết. Yêu cầu người dùng đăng nhập bằng Twitter và sau đó liên kết tài khoản Facebook.

Rõ ràng điều này sẽ dễ dàng và đơn giản hơn nếu mọi người sử dụng cùng một địa chỉ email và Twitter thực sự sẽ trả lại địa chỉ email. Nhưng không phải ai cũng làm như vậy bạn phải xử lý trường hợp cạnh này theo cách tốt nhất có thể - tại thời điểm này tôi sẽ thử tùy chọn khớp và chỉ đẩy người dùng xác thực với các dịch vụ khác khi họ đăng ký và điền thông tin tiểu sử.