Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow resources to auth with multiple methods #453
This change allows resources (e.g. User) to authenticate through multiple methods for the same real life person. Prior to this, each auth method (e.g. facebook, twitter, etc) would create a new row in User when it was used.
It's inspired off the back of a number of issues raised around multiple authentication methods (particularly with oauth), primarily a longstanding issue #23. Within that issue there is suggestion of plans A and B, which in short are:
These are both valid ways of accomplishing this end, so we've largely followed:
We've done this by trying to avoid being opinionated about how users should implement their third party domain objects (e.g. FacebookUser or TwitterUser) and what relationship they may have to the authenticating resource.
For more information on the approach we've taken, check out the README changes we've made, specifically this section.
There are a couple of conceptual changes worth highlighting in this PR:
1. Dropping usage of provider/uid columns when allowing multiple auth
The main issue we had with the existing implementation was the reliance on the
2. Restructuring the uid field in the http header
The main thing which we'd like opinions on is the change to the
We wouldn't need to worry about what
So the big question is how do we pass around the
A quick table of (what we think) the pros and cons are:
We've implemented option 2, but aren't particularly set on it. The primary reason was a concern about being backwards compatible and not adding more fields to the http header, as there are already quite a few of them.
Ultimately though, we're leaning towards option 1 now that we've finished the implementation, so input here would be much appreciated!
Just an FYI for anyone coming to this - this is a fairly stale PR, and I'm not sure when/if it will get reviewed.
I no longer have any projects that use devise (let alone devise_token_auth) so am not planning on doing anything with this, even if code review comes back. Mainly because as far as I know (@ram535ii can correct me on this!) I don't think this version of the code is running anywhere in production. Consequently, I would think it sensible to have a reasonably chunky change like this running in a production environment (which it was when we raised the PR) before having a merge to
I'll leave it open in case it's useful for anyone (or if anyone else is happy to rebase/refactor/make review changes), but use with care as it's pretty far behind
@lynndylanhurley - if you don't think this is something you want to incorporate into the gem, I have no problem with you closing this given all this.