The support for authentication needs to be modularized and moved to cards plus plugins.
A large part is this is on the new_traits branch already. User model and users table is mediated by class methods in accounts.rb (currently in app/models, but likely to move). At this point it supports finding the user's authentication object (card.user on +*account cards) by email (and implicitely, by the account card and it's trunk, the "card with account", cannonnically a User card or WagnBot and Anonymous built-in cards). Current Wagn configuration is to only use email as the external key for accounts. This is how it will stay, and Wagn can be configured for other login keys (User name, etc.)
The bigger fish is alternative authentication providers, twitter, google, facebook, open-auth and so forth. The will have a greater variety of attributes and keys required and available.
We need to now bind everything through the account cards and factor out the special admin and account controllers. Patterns and sets related to the +*account cards will provide the additional and custom attributes for the particular auth providers.
It may make sense to use plugins that extend a new cardtype with its custom attributes and methods.
I think this means that the User model needs a cardtype, User is taken, so maybe WagnUser, or WagnAccount ?
so for our current system we need:
email, crypted password, salt
for twitter we need:
handle
... and then... how does it work? we just need site-specific twitter details at that point? I assume we want to store that stuff in cards too?
consumer key / consumer secret
I suppose my sense is that a given card can have only one account, though it may have multiple sign-in methods. Is that what you're thinking?
if so, I think I would suggest that it should looks something like this:
Gerry+*account (perhaps the content of this card can be the account status? there will only be one status; if blocked, it's blocked for all signins)
Gerry+*email each account can only have one authoritative email, no?
Gerry+*twitter (via packs). content is handle, eg @ddenizen
Gerry+*openid (via packs). content is openid url.
And then, there is a root level
*twitter key
*twitter secret
What about openid? Gotta to be some extra info there somewhere, right? :)
I would think we'd only need an additional type if we couldn't identify the cards through names, no?
Perhaps it would make this clearer if we got a bit more concrete. let's say we want a twitter account. What information do we want to store? A handle and a password?
perhaps that could be done with a +*twitter card that includes either +*handle or "_left+*twitter handle". If so, we can deal with all of that without a new type, no?
I was thinking that custom login attributes are accessed from a common +*account card, so then +*account would need to have another dimension to select which provider. My question is why not a type? we are using the tag to say it is an authorizable entity, but we could have +*twitter_account and +*oauth_account. I don't have a strong preference, but I think one attribute name is cleaner.
Maybe the representation is a pointer card that has one or more possible cards that have an auth-provider behind them and we could just use any patterns to get the custom functions of a specific provider.
--Gerry Gleason.....2012-11-15 20:00:04 +0000
Let's say I package our User class as a provider, call that WagnAccount and connect it to the RightAccount sets. Now I add a twitter provider, how do I say that the Gerry user can log in locally (User model) or use twitter?
--Gerry Gleason.....2012-11-15 20:04:10 +0000
I could imagine storing in the account (+*account) card content a whole authorization configuration for the user. Maybe use Json (sort of like Search cards and wql, the underlying rep is just different. Has some real potential combined with obj_render branch integration.
--Gerry Gleason.....2012-11-15 20:07:40 +0000
I think it would be helpful for me to play with sample data (maybe in the example card?). Let's say we have a user named Horace who has a standard wagn login info and is also set up to log in with twitter or facebook. What all information might we want to store about him?
If we get some play data, the we can move back and forth between representation and implementation ideas.
--Ethan McCutchen.....2012-12-06 21:14:25 +0000
Sounds good. I'll use the example of twitter (and maybe openId if I can do two, FB if three). I think abstractly, there is a primary key to identify the login, email for Wagn logins and many others, twitter @id is a simple user name, the only issue is name validation in most cases. That key can have a characteristic name, but maybe we use something like :account_identity. The value and validations would be up to the auth provider, but it should include any standard syntax markers (i.e. the @ is @ddenizen and the @'s and .s in email gerry@geraldgleason.com, or http://myopenid.geraldgleason.com/gerry for open id ...)
--Gerry Gleason.....2012-12-10 19:26:04 +0000
Gerry+*account+*twitter -> (content) @ddenizen
Gerry+*account+*email -> gerry@geraldgleason.com
Gerry+*account+*openId -> http://gerry.openid.geraldgleason.com/
--Gerry Gleason.....2012-12-10 19:33:51 +0000
OmniAuth twitter strategy I wonder how hard this will be now ...
--Gerry Gleason.....2012-12-10 19:39:25 +0000
I think that as with email, we will be able to reference these as: Gerry+*twitter ... as well, but it will be bound to the +*account cards to be able to use it with a session.
--Gerry Gleason.....2012-12-10 19:41:45 +0000
I only took a brief look at OmniAuth and OmniAuth twitter. My guess is that we'll often be good with rack extensions (like OmniAuth) more or less unaltered. Rails gems will be a little more hit or miss; we'll especially have to avoid those that add data structure. But I don't see that with a brief glance.
It does look like both expect data to be in place at run time, so we may have degree of complication around card-based configuration. Wondering if one of the common "events" isn't going to be re-load...
--Ethan McCutchen.....2012-12-10 22:12:48 +0000
+discussed in support tickets
+relevant user stories