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

If user is logged in, the email validation does not have immediate effect #88

Closed
szmiklos opened this issue Oct 11, 2017 · 4 comments
Closed
Labels
Milestone

Comments

@szmiklos
Copy link

wicked.portal

Problem

If I sign up on the portal i will be navigated to the page 'applications', here is a message like "you have to validate your email". I keep open this page and go validate my email. When im done i navigate back to the 'applications' page and refresh but nothing happens, i just see the same message ("you have to validate your email").

Suggestion

When you validate your email, should save this state immediately. My suggestion: should set user's validated property true in to the user session in function handleEmailVerification() (portal/routes/verification.js).

@DonMartin76
Copy link
Member

It probably doesn't get re-read until you re-login, which is not quite desired behavior, I agree. Will look into it.

@vivekpd15
Copy link

+1 @DonMartin76 Any updates on this? Would really appreciate any kind of help on this.

@DonMartin76
Copy link
Member

The code has evolved a real great bunch from the 0.12 release in the mean time, and this portion is something which will go out of the portal implementation completely (and into the default authorization server). I'll see if I can throw in an intermediate release 0.12.2 before we can go for a 1.0.0 beta release. There are a couple of other candidates for such a release.

@DonMartin76 DonMartin76 changed the title email validation If user is logged in, the email validation does not have immediate effect Nov 27, 2017
@DonMartin76 DonMartin76 added this to the 0.12.2 milestone Nov 27, 2017
@DonMartin76
Copy link
Member

OK, this is a little stupid, as this is quite interwoven with passport.js. Passport handles everything by a little magic, and thus the user settings are copied into the req.user property during one of the middleware handlers in the generic code. Updating the validated property here wouldn't do anything, unfortunately, so I fixed this via a small hack which updates the internal session state of passport.

I strongly dislike this, but it currently works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants