Closed sorenbs closed 7 years ago
I'm looking for this feature too, exactly this 4 steps are missing. Beside that: if connected to different Oauth services like Facebook, Twitter a merging into the same User might be nice
Another nice feature would be to have a refreshToken of some sort. It sounds like the current token expires in 30 days.
In my case I would want the token to be refreshed for another 30 days automatically from my app every time the user opens the app - without requiring them to input username and password again.
I could store username and password on the client side - but would like to avoid that if possible.
More biz logic: Reset link expires after a short period of time Reset link is single use only
Thanks @mypark. That input is super helpful. Keep us posted with more thoughts. We'll reach out with an API proposal soon.
I would like to 1up this. Especially having no way to reset the password is painful.
Further, I'd like to remember that special use cases (expiration, single use of x-links, validation of password format, validation of username, validation of e-mail and so on) can be easily implemented as soon as #58 is in place.
Thanks for the feedback! We're currently working on integrating email/passwords in the updateUser
mutation. Using the mutation and the permission system, you can then build an elaborate email/password workflow using microservices.
We will extend the updateUser mutation like this:
mutation {
updateUser(id: "existing-id", email: "optional new email", password: "optional new password")
}
You will be able to use the permission system to specify for example that only the user, only an admin or no-one should be able to update auth values.
We will store the new password securely, but not validate the new email
Hi @sorenbs it would be helpful for us developer to get a token for double-optin email auth. Any plans to include this?
Hi @dohomi !
Right now we will simply extend the updateUser mutation as described. We will not yet build the 5 features described in the original issue.
would your use case be solved by the 5 features in the original issue?
@sorenbs the most helpful feature would be a reset-password
function which sends out an email with a token (valid for 12h) where a user clicks on it and can specify a new password. I simply don't like the idea of sending plain passwords through email around, it feels old-school and unprofessional and kind of unsecure as well.
The reset password updateUser
mutation is great, but how can I validate that this user has the right to do so if he is not logged in?
With the new updateUser
mutation you have the ability to build your own infrastructure around this use case, including generating the token as you described. And on the other hand, it's the first step in offering more elaborate workflows as described in this issue :slightly_smiling_face:
@marktani looking forward for this feature!
@sorenbs did you publish the updateUser
mutation already with the described changes? Inside of the playground the autocompletion doesn't show password
neither email
yet.
That's not released yet, I'll write an update here when it's avaialbel :slightly_smiling_face:
still no update?
I'm curious about an update on the updateUser mutation as well - the updateUser mutation would be useful as the auth0 implementation has been causing me some grief and I'd prefer not to use the auth0 integration if possible.
This feature would be the most critical for my business: currently, users who have registered and have misplaced their passwords have to manually reach out to me, I delete their account, then they have to create a new account (and thus loose data currently associated with their account).
Thanks for staying on top of this everyone and sorry for the inconvenience here! :pray:
Amongst other exciting features, we recently pushed out multiple new data regions (see #61) which took longer than expected. We've been preparing a general approach to keep up with the feature requests surrounding authentication (including the features mentioned in this thread) and are now ready to fully commit on implementing it :slightly_smiling_face:
I hope you can hold out a little longer. Thanks for your patience! :raised_hands:
I hope this feature will be implement before my production release. Thanks graph.cool team!
With
mutation {
updateUser(id: "existing id", password: "new password")
}
Is it possible to require sending the old password for verification?
Related - for any field, is it possible to send both old and new values so we can use them in permission queries?
For example for my email verification flow I want to set isVerified
to true
and some secret
to null
, but only if the secret was known in the first place. I can probably solve this with two mutations but that won't always be the case.
Hi. I'm just wondering if I could get a rough estimate on when we will be able to update a users password.
I'm also still waiting the reset password function. Please give some update about this..
same here ... waiting for this feature
Hey everyone - we have started working on this :-)
progress tracker?
I hope this includes "change password" mutation.
@sorenbs Thanks for prioritizing. Hope you guys can push it soon, I bet reset password and verification link features delay a good number of developers from going into production.
I don't think a verification e-mail will be part of this, since you can already built that on top of Graphcool.
We have a function using the Server Side Subscription:
subscription {
User(filter: {
mutation_in: [CREATED]
}) {
updatedFields
node {
id
email
}
}
}
Function (pseudo-code for brevity):
module.exports = event => {
const id = event.data.User.node.id
const email = event.data.User.node.email
const secret = getRandomSecret()
return storeSecretOnGraphcool(id, secret).then(() => sendVerificationEmail(email, secret))
}
Using a permanent access token for storing and Mandrill for sending the email. Make sure you set your permissions so that a user can't read or write his own secret.
For the actual verification our mutation looks like this:
mutation ($id: ID!, $secret: String!) {
updateUser(id: $id, secret: $secret, isVerified: true) {
id
isVerified
}
}
And the permission (for isVerified
and secret
fields, name your fields differently if you want to support anonymous authentication) to make sure the secret is correct:
query ($node_id: ID!, $user_id: ID!, $input_secret: String!) {
SomeUserExists(filter: {
AND: [
{
id: $node_id
},
{
id: $user_id,
secret: $input_secret,
isVerified: false
},
{
secret_not: null
}
]
})
}
Hope this helps!
A forgot password reset link can probably also be built on top of Graphcool as long as email and password are mutable.
any update on this? hard to go to production (and hence, pay money to graphcool) without password reset...
Hold on, @tsdexter, it should be done soon... @marktani said itโs their top priority.
@sorenbs any idea of when this will be ready? ๐
Definitely looking forward to this feature. If you guys need to take any inspiration or pointers, then I think the Firebase team do a really great set of authentication tools:
https://firebase.google.com/docs/auth/web/start
In addition to all your development, it would also be great to be able to modify any system emails to our liking. Perhaps an area in the console that we can edit email templates?
I think a solid authentication system is the foundation to using graph.cool in production. At the moment the lack of flexibility on authentication is the only thing holding me back right now.
Thanks for all your work ๐๐ผ
Hey @michaelpumo and everyone else :wave: We are currently running a closed beta for custom authentication that allows you to implement your own authentication logic. Examples for Google, Auth0 & more, but also Email/PW are available.
You can also use this to integrate with Twitter, AWS Cognito or Firebase Auth and other authentication solutions.
This feature also allows you to build your own workflows around forgot password/verify email for example. If you're interested in participating in the beta program, please reach out to me in Slack ๐
Waiting and looking forward to this feature, would be nice to have this feature in my final production release. Thanks, graph.cool team, your work is awesome, extremely good!
Subscribing, also, any updates?
Did you have a look at the Email/PW example? While it's still in beta, it's in a solid state. The examples in the repo show how the possibilities with custom authentication resolvers.
Does this mean we have to make our own custom authentication provider to be able to update passwords? Is the updateUser mutation still being worked on to allow for updating the password with the graph.cool email provider?
Does this mean we have to make our own custom authentication provider to be able to update passwords?
Yes, that's correct. We'll slowly transition away from the authentication providers in their current form towards custom authentication. A relevant discussion in the forum can be found here: https://www.graph.cool/forum/t/a-question-concerning-the-future-of-the-authentication-features/494
Okay, so eventually there will be no email provider from graph.cool?
I'm just wondering if it will be completed obsoleted and removed. If that's the case, I know I should probably just move to custom authentication sooner rather than later.
@lastmjs My understanding is that @marktani was referring to the preconfigured authentication providers (you can set them in the console by going into the User
type and clicking in the top-right corner) when he said they were migrating away from themโnot the custom email authentication processes, as mentioned here.
(just making sure I correctly understood what you said).
If it helps to know, I used to use the Email Auth Provider and recently migrated to the custom authentication system, because users werenโt able to reset their passwords or change their email addresses using the Email Auth Provider setting. Let me know if youโd like assistance with migrating.
Hey @lastmjs, we'll discontinue the email password auth provider and all other integrations sooner rather than later.
An improve CLI version is currently being tested in early beta, where we are testing a simple module concept amongst other things.
Modules come with a slightly worse "out-of-the-box" experience than auth providers, but instead of zero control previously, developers now have full control over functionality, the interface, evolving the code etc.
We're currently compiling a set of ready-made modules, one of which is the email-password
module: https://github.com/graphcool/modules/tree/master/authentication/email-password
Everyone in the community is invited to participate in the discussion for existing modules and to make suggestions for new ones. Apart from that, you are free to create your own modules to improve modularity and reusability in a Graphcool project.
Please reach out to me in a PM in the Forum if you're interested to participate in the beta now. We'll announce more information about the new CLI and which changes it brings soon.
Hi @marktani I can't seem to find the private message button in the forums :( I would like to participate in the beta as well.
@johhansantana Click the 'message' button on this page: https://www.graph.cool/forum/u/nilan/ :smile:
@kbrandwijk I really can't find it ๐
here's a screenshot
Just sent you a PM in the forum, @johhansantana ๐
Resolver functions offer new workflows for custom authentication, that allow you to add most features mentioned in the OP. You can find example templates in this repository: https://github.com/graphcool/templates
Therefore, I'm closing this issue ๐ Thanks a lot for all your feedback on this!
I've been playing around with this and it really works nicely, good job!
Am I correct when saying functions run with admin privileges automatically? The template said to create a PAT for each function but this wasn't needed. This is fine and actually probably more in line with expectations.
A way to get current logged in user would be nice though!
Am I correct when saying functions run with admin privileges automatically? The template said to create a PAT for each function but this wasn't needed. This is fine and actually probably more in line with expectations.
We'll clarify the mechanism for this going forward here: https://github.com/graphcool/graphcool/issues/219.
A way to get current logged in user would be nice though!
This is again up for discussion (same feature request as above), but here's a way how to currently do this: https://github.com/graphcool/modules/blob/master/authentication/email-password/src/loggedInUser.js
Looks good, thanks!
The Email Auth Provider should support: