Logic & Social Auth

[brandonmp]

i've been implementing a series of logic functions similar to the slackr example & am hitting problems w/ social auth.

the slackr example uses regular username/password accounts, so the flow works fine--that is, hooking a function to createUser. it makes sense to mutate payloads at that step b/c you won't accidentally overwrite existing information.

Social login is diff't though. since user account is created by the server upon first login, any createUser Logic is fired with a minimal payload.

I'm implementing something like your slackr example, but w/ social auth. How I've decided to do it is to hook the group-add logic to the pre-operation of updateUser. then, when user logs in for first time, I send them to profile validation page, and update their account on 'save'. This sends the data I need (invitation ID, user email, etc.) to the Logic function.

However, since it's connected to updateUser, I have to make sure that none of the mutation code fires on subsequent update calls. This isn't intractable, but it creates the opportunity for error.

For now I have a special field where I pass an argument to the Logic (eg, validateGroupInvitation: boolean), which checks for it in the payload to determine if it should fire.

i think this can be fixed by either allowing arbitrary fields to be passed with the loginWithAuth0* mutations (eg, add emailAddress such that createUser payload passed to Logic includes it)

or by adding a built-in way to pass a meta argument to scaphold with the mutation payload. eg, { input: {...}, args: {arbitrary: 'blah'}}. I am half sure that'd screw up client side gql query validation, though.

in general having some way to selectively fire a Logic function on some, but not all, calls to a certain mutation would be clutch, though maybe the custom queries you've mentioned will obviate this

[mikeparisstuff]

This is good. Perhaps we can expand the createUser to accept a dynamic authCredential instead of username/password. That way you could associate the user with the social provider & pass information for that user to be created with.

[mikeparisstuff]

Would love to hear thoughts on this.

[brandonmp]

i think that's heading in the right direction, but can we simplify further? the login flow for social is kind of ugly. in my app it's:

1. login user to auth0 endpoint
2. initialize my graphql client, making sure idToken is not present in headers
3. make login mutation
4. add idToken to headers on already-initialized graphql client (a relative pain in the ass in relay, not sure about apollo)
5. if user is new, get whatever registration data from them and call updateUser
6. hydrate app state

so allowing social credentials in createUser would cut out a few steps, but ideally, i'd love to be able to create the user with an auth credential and log them in with 1 round-trip to the server.

i like the utility of auto-creating an account on login, so if it's possible to solve this w/o giving that up, i think that'd be optimal