-
Notifications
You must be signed in to change notification settings - Fork 38
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
register page #428
Comments
@xauxatz there is "default_route" in private zone. Here you can set any route inside private zone, and application will redirect to that route after login & register. |
But I only want to modify the route taken from the "register" page, not all other pages within the "private" zone. Is this possible without going into the code? |
Hum... tracker fires when Meteor.userId() is changed (which is the same both on register and on login). You can simply add one redirect command into form's onsubmit event (you can do it directly in the code - kitchen will not overwrite your code as long as you are are running it from any git branch other than "meteor-kitchen" branch). |
like this? |
Meteorkitchen generates this code in the event handler for "register":
I have tried in many ways to get the submit to redirect to another page as seen next to "MY INSERT". However, nothing I do will make the program redirect to anything else than "home_private" |
@xauxatz there is proper way (without hacks) to do that, but only if user is not allowed to visit other pages until he/she enters additional info after registration (I guess this is your intention?) You can add one more user role named something like “newcomer”, set that as default_user_role (in app object) and restrict access to private_home to “newcomer”, allow only settings page. In settings page, on form submit call method which will set user’s role to “user”. That way, newly registered users (newcomers) will redirect to settings page (because home page is restricted to them), and after they enter required info, their role will became regular user. On next login, user will be redirected to home page (because his role is now “user”). Does this helps? |
Other ideas: in users collection, add login_counter (could be useful anyway for admin to track user’s app usage) and if Meteor.user().profile.login_count==0 redirect. can be code added to home page’s route hooks. And increase login count on_user_logged_in. That way, user will be redirected after registration (but home page is not restricted to him), and in next login his login count will be > 0 (or > 1 depending on where you are increasing counter) and will not redirect. |
(you need to store some flag about user anyway - simple redirect in registration form will not work because router redirects user from that form imediatelly when user is logged in, and there is no difference betwen “just registered” and “logged in”. |
This is what I want to do and your suggestion is helpful.
I do want to collect more information from the user before allowing him
to get to "home_private".
In principle I would like two user roles then, "user" (normal one) and
"non_approved".
"non_approved" should only be able to view the "user_settings" page
until this is satisfactorily filled in. Then he should be converted to
"user" and be allowed to access other pages in the "private" section.
But it seems impossible to get this behavior as I cannot force the
redirect from "register" to go anywhere else than "home_private".
Is there a place where I can override default routes, as this seems to
be the simplest approach forward?
…On 12/1/2018 10:43 PM, Petar Korponaić wrote:
@xauxatz <https://github.com/xauxatz> there is proper way (without
hacks) to do that, but only if user is not allowed to visit other
pages until he/she ebters additional info after registration (I guess
this is your intention?)
You can add one more user role named something like “newcomer”, set
that as default_user_role (in app object) and restrict access to
private_home to “newcomer”, allow only settings page. In settings
page, on form submit call method which will set user’s role to “user”.
That way, newly registered users (newcomers) will redirect to settings
page (because home page is restricted to them), and after they enter
required info, their role will became regular user. On next login,
user will be redirected to home page (because his role is now “user”).
Does this helps?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#428 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJsY8atqu8VAmsl4OyrL0uNQIsCjTAFxks5u0vf0gaJpZM4Y5vXm>.
|
@xauxatz I will make example for you, later today when I reach my computer. |
@xauxatz here is example app: https://www.meteorkitchen.com/app_details/about/MuNW4J96D962bF7GT |
When user is registered, he gets role "unverified" and cannot access "home_private", so router redirects user to first allowed route and that's "user.settings". I added field "profile.phone" to user settings, and make it required field. After user submits form with phone entered, following code fires at server: Users.after.update(function(userId, doc, fieldNames, modifier, options) {
if(doc.roles && doc.roles.indexOf("unverified") >= 0) {
var set = modifier ? modifier.$set : null;
if(set) {
set = objectUtils.deepen(set);
if(set.profile) {
// Check if user entered phone number and set user's role to "user"
if(set.profile.phone) {
Users.update({ _id: userId }, { $set: { roles: ["user" ] }});
}
}
}
}
}); Note: for all new pages you add in "private zone" that "unverified" user is not allowed to access, make sure you've set:
That's it. But... this means user will self-verify (in this example, I added "phone" as example), and nobody guarantee you that user will enter valid information. So... I believe you want admin to approve user after user enters his info? If so, please let me know and I will make example for you. |
Many thanks - I hope others will also benefit from this! |
👍 |
Is there a way to modify which page the app goes to after register "submit" ?
I have searched long and wide and cannot seem to find anywhere in the CLI where this can be modified.
The text was updated successfully, but these errors were encountered: