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

bug #930: added email property check, ensuring the correct response. #1066

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

dev-rahulbhadoriya
Copy link

Closes #930

Added a check for the email field. If the property is missing or not included in the request body, an error 400.23 ( propertyNotFound) will be returned.

{
    "message": "Could not find a property named 'email'",
    "code": 400.23,
    "details": {
        "property": "email"
    }
}

What has been done to verify that this works as intended?

Tested with postman.

Why is this the best possible solution? Were any other approaches considered?

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Does this change require updates to the API documentation? If so, please update docs/api.md as part of this PR.

Before submitting this PR, please make sure you have:

  • run make test-full and confirmed all checks still pass OR confirm CircleCI build passes
  • verified that any code from external sources are properly credited in comments or that everything is internally sourced

@matthew-white
Copy link
Member

matthew-white commented Dec 20, 2023

Thanks, @dev-rahulbhadoriya! I have a couple of small suggestions. First, I think we should use Problem.user.missingParameter instead of propertyNotFound. Currently, we only use propertyNotFound when validating the $select OData query parameter, where the Problem means "you specified a property that doesn't exist." In other cases, it's more common that we use missingParameter, which has more of a meaning of "you didn't specify a parameter that we expected."

It'd be great if you could also add a test to test/integration/api/users.js for the new behavior. The test could send a request without email, then assert that the resulting response body has correct values for code and details.

Also, just FYI, the project is going to be quieter for the next couple of weeks. You may find that additional review is delayed until 2024. Thanks again for submitting this PR!

@dev-rahulbhadoriya
Copy link
Author

@matthew-white , thanks for the suggestions and for reviewing my PR. I have corrected the code and added a test case for it. Kindly check and review it

Comment on lines 406 to 410
it('should fail the request if email field is sent blank in request body', testService((service) =>
service.login('alice', (asAlice) =>
asAlice.post('/v1/users/reset/initiate')
.send({ email: '' })
.expect(400))));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind also adding assertions about the response body? code should equal 400.2, and details should equal { field: 'email' }.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can do something like this ?
it('should fail the request if email field is sent blank in request body', testService((service) => service.login('alice', (asAlice) => asAlice.post('/v1/users/reset/initiate') .send({ email: '' }) .expect(400) .then(({ body: { code, details } }) => { details.should.eql({ field: 'email' }); code.should.eql(400.2); }))));

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.

Return better error message when email is not specified
3 participants