Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support asynchronous validators #5

Merged
merged 1 commit into from
Oct 27, 2016
Merged

Support asynchronous validators #5

merged 1 commit into from
Oct 27, 2016

Conversation

canac
Copy link
Contributor

@canac canac commented Mar 1, 2016

In my application, I need asynchronous validators. In this PR, $awaitUser now supports asynchronous user validation functions that return a promise. If the validation function returns a promise, the resolved value will be used to determine the user's validity. Also, if it returns a rejected promise, the rejected value will be used as the validation error object. Synchronous validators are still fully supported.

@DAB0mB
Copy link
Collaborator

DAB0mB commented Mar 1, 2016

Why would you need an async validation? Can you please give an example?

@canac
Copy link
Contributor Author

canac commented Mar 2, 2016

@DAB0mB Great question! In my application I use the alanning:roles package, and in my ui-router routes definition, I have a resolve function that uses $auth.requireValidUser to verify that a user has the admin role before giving them access to the admin portion of the site. I have a subscription set up to send me the current user's document, which includes the roles field used by the roles package. However, Meteor automatically publishes the user's profile, username, and emails fields. Thus, for a brief moment during app startup, the document returned by Meteor.user(), will exist and have a few fields, but it will not yet have all of them. This matters because a naive requireValidUser validator like user => Roles.userIsInRole(user, 'admin') will sometimes fail on startup if the user document does not have the roles field loaded yet.

There are a couple ways of solving this problem. One is to change the logic in $$Auth.$awaitUser to also wait for the user to have a roles field. This approach is too specific because it would break code that does not use the roles package. Another way would be to use asynchronous validators to wait to validate the user until it has the roles field. It is a very complex situation, but that is my use case for wanting asynchronous validators. However, if you have a recommendation for another way to solve this problem, I would love to hear it!

@canac
Copy link
Contributor Author

canac commented Mar 14, 2016

@Urigo @DAB0mB Have you decided whether this pull request will be merged or not? Is there anything I can do to increase its likelihood of being merged?

@Urigo
Copy link
Owner

Urigo commented Mar 30, 2016

@canac maybe let's schedule a meeting on Hangouts?
you can ping me on gmail

@santiq
Copy link

santiq commented Jun 2, 2016

What happend with this PR ?

@canac
Copy link
Contributor Author

canac commented Jun 2, 2016

@santiq Nothing, yet. Do you need this feature too?

@santiq
Copy link

santiq commented Jun 2, 2016

Yes, I need this too as I'm having the same issue

If the validation function passed to $awaitUser returns a promise, the resolved value will be used to determine the user's validity.
@canac
Copy link
Contributor Author

canac commented Jun 4, 2016

There were merge conflicts, so I just rebased off of master to fix those.

@Urigo Urigo merged commit 911b3ef into Urigo:master Oct 27, 2016
@Urigo
Copy link
Owner

Urigo commented Oct 27, 2016

well, that took a while for us :)

sorry about that @canac

@canac canac deleted the asynchronous-validators branch October 31, 2016 02:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants