-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Improve email verification #3681
Improve email verification #3681
Conversation
@aontas updated the pull request - view changes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks good to me and is a nice catch. Would like @flovilmart to take a look at too.
@acinader that's a hot fix, but we need something for those protected fields, declared at the class level. Also we strip authData and password from the responses, I believe this should be stripped at the same spot no? |
@flovilmart So you would prefer the logic I added in UsersRouter to instead live in the cleanResultOfSensitiveUserInfo function in RestQuery.js? And move the other logic (disallowing emailVerified update) to the UserController? When I put these changes in, would that be enough to satisfy your comments? If not can you provide some more direction as to what you would consider appropriate? |
@aontas I believe we should keep it in the responses, unless that causes an issue... (http://docs.parseplatform.org/rest/guide/#verifying-emails), only for the current user. perhaps we should validate that the update don't contain the emailVerified here: https://github.com/parse-community/parse-server/blob/master/src/RestWrite.js#L346 |
@flovilmart There is nothing in this PR that removes the emailVerified flag from the responses. I agree that it is required to stay there. The only things that are removed are internal data members, which have been denoted by a leading underscore (ie, "_email_verify_token" which is the secret provided via email). I will move the logic to check the incoming emailVerified data in RestWrite. |
Codecov Report
@@ Coverage Diff @@
## master #3681 +/- ##
=========================================
+ Coverage 90.22% 90.3% +0.07%
=========================================
Files 114 114
Lines 7491 7498 +7
=========================================
+ Hits 6759 6771 +12
+ Misses 732 727 -5
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small fix, otherwise we'll miss out some test :)
spec/ParseUser.spec.js
Outdated
@@ -26,7 +26,7 @@ function verifyACL(user) { | |||
expect(perms['*'].write).not.toBe(true); | |||
} | |||
|
|||
describe('Parse.User testing', () => { | |||
fdescribe('Parse.User testing', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops
Oops. Yeah. Fixed now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aontas still a few pending questions here and there. Thanks for the work you're putting onto it!
spec/ParseUser.spec.js
Outdated
verifyUserEmails: true, | ||
emailAdapter: emailAdapter, | ||
publicServerURL: "http://localhost:8378/1" | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reconfigureServer returns a promise, can you handle that please?
const user = new Parse.User();
user.set({
username: 'hello',
password: 'world'
});
reconfigureServer({
appName: 'unused',
verifyUserEmails: true,
emailAdapter: emailAdapter,
publicServerURL: "http://localhost:8378/1"
}).then(() => {
return user.signUp()
})
...
spec/ParseUser.spec.js
Outdated
sendMail: () => Promise.resolve() | ||
} | ||
|
||
reconfigureServer({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as above
@@ -57,6 +57,17 @@ export class UsersRouter extends ClassesRouter { | |||
const user = response.results[0].user; | |||
// Send token back on the login, because SDKs expect that. | |||
user.sessionToken = sessionToken; | |||
|
|||
// Remove hidden properties. | |||
for (var key in user) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a quick question,
Those fields get stripped only when calling /me, but not when let's say we make an unauthenticated query?
Could we add a test for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What sort of unauthenticated query would we want these fields to be available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the point, we won't. But those fields would only be stripped here, not everywhere we need them to be stripped
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There does seem to be handling somewhere that removes hidden fields (see updated test where users/ is retrieved without hidden field).
The general case where all hidden fields are removed from all unauthenticated queries is likely better to be talked in its own issue, rather than tacked on to this PR.
Does this current version require any further changes?
Ok. I'll have a look in the next few days.
…On Mon., 24 Apr. 2017, 9:59 am Florent Vilmart, ***@***.***> wrote:
***@***.**** requested changes on this pull request.
@aontas <https://github.com/aontas> still a few pending questions here
and there. Thanks for the work you're putting onto it!
------------------------------
In spec/ParseUser.spec.js
<#3681 (comment)>
:
> @@ -2784,4 +2784,74 @@ describe('Parse.User testing', () => {
done();
});
});
+
+ it('should not allow updates to emailVerified', done => {
+ var emailAdapter = {
+ sendVerificationEmail: () => {},
+ sendPasswordResetEmail: () => Promise.resolve(),
+ sendMail: () => Promise.resolve()
+ }
+
+ reconfigureServer({
+ appName: 'unused',
+ verifyUserEmails: true,
+ emailAdapter: emailAdapter,
+ publicServerURL: "http://localhost:8378/1"
+ })
reconfigureServer returns a promise, can you handle that please?
const user = new Parse.User();
user.set({
username: 'hello',
password: 'world'
});
reconfigureServer({
appName: 'unused',
verifyUserEmails: true,
emailAdapter: emailAdapter,
publicServerURL: "http://localhost:8378/1"
}).then(() => {
return user.signUp()
})
...
------------------------------
In spec/ParseUser.spec.js
<#3681 (comment)>
:
> + done();
+ }).catch((err) => {
+ expect(err.message).toBe("Clients aren't allowed to manually update email verification.");
+ done();
+ });
+ });
+
+ it('should not allow updates to hidden fields', done => {
+
+ var emailAdapter = {
+ sendVerificationEmail: () => {},
+ sendPasswordResetEmail: () => Promise.resolve(),
+ sendMail: () => Promise.resolve()
+ }
+
+ reconfigureServer({
same as above
------------------------------
In src/Routers/UsersRouter.js
<#3681 (comment)>
:
> @@ -57,6 +57,17 @@ export class UsersRouter extends ClassesRouter {
const user = response.results[0].user;
// Send token back on the login, because SDKs expect that.
user.sessionToken = sessionToken;
+
+ // Remove hidden properties.
+ for (var key in user) {
just a quick question,
Those fields get stripped only when calling /me, but not when let's say we
make an unauthenticated query?
Could we add a test for that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3681 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEtyzHRTsvcYLFdBWmkcDI3XjEMIX_cvks5ry8mvgaJpZM4MvMky>
.
|
PR #3768 seems to have caused this build to fail. It was merged even though the build failed: https://travis-ci.org/parse-community/parse-server/builds/227340428 |
Let's merge that one for the upcoming release, Thanks @aontas ! |
This should fix the issues as outlined in #3393 and #3432