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

Implemented user authentication #32

Merged
merged 36 commits into from
Oct 5, 2023
Merged

Conversation

Alekseeybg
Copy link
Contributor

No description provided.

Alekseeybg and others added 19 commits September 13, 2023 15:56
…enerate jwt tokens. Authenticate users. Added request/response DTOs. Refactored existing code
…TestBase and added Authorization headers with valid token to every request.
…Changed how we secure the secretKey. Configured tests so they work again.
[feature-22] Resource availability by resource and total resource quantity. test -> main
…validation/exception handling. Custom exceptions thrown with custom error messages showing correctly.
… created/thrown/handled. Validation to UserRequestDto.
Copy link
Contributor

@VladoKat VladoKat left a comment

Choose a reason for hiding this comment

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

The logic for validating the jwt token seems more complex than I thought it would be. We have a lot of exception handling that I am not sure when we are supposed to hit. If we have cases in which these scenarios could happen, then I suggest creating tests for them. If not, we should consider simplifying the code. (I am not saying I know how but would love to dive deeper and try to understand it)

pom.xml Outdated Show resolved Hide resolved
src/main/java/jewellery/inventory/service/AuthService.java Outdated Show resolved Hide resolved
Comment on lines 92 to 95
void testInvalidUrlReturnsUnauthorized() {
ResponseEntity<Void> response =
testRestTemplate.exchange("/invalid-url", HttpMethod.GET, null, Void.class);
assertEquals(HttpStatus.UNAUTHORIZED, response.getStatusCode());
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we need this test case. We are supposed to return 401 for every request that is not authorized (except for the post to /auth/token). If a request is authorized but the url is not valid, then we should return 404. Is this not the case currently?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed it. The idea came from a colleague of mine who told me what integration tests they write for their project.. And with spring security I do not know how to make it so it returns 404 Not found instead of unauthorized for not existing endpoints... I think the default behavior is to return always unauthorized. I just tested - tried to hit not existing endpoint and provided valid token in the headers - it returned 401 unauthorized.

Copy link
Contributor

Choose a reason for hiding this comment

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

hm, that's interesting. I wonder why...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Probably because we override the default behavior and tell it to return 401 instead of 403 🗡️


private String generateExpiredToken() {
Date expiredDate =
new Date(System.currentTimeMillis() - (1000 * 60 * 60 * 24)); // 1 day in the past
Copy link
Contributor

Choose a reason for hiding this comment

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

Please, remove the comment. You can, instead, extract the complex calculation (1000 * 60 * 60 * 24) in a variable named dayInMillis.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

Copy link
Contributor

Choose a reason for hiding this comment

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

I see you ended up not extracting dayInMillis = (1000 * 60 * 60 * 24). Any reason why not?

…ion tests failing after changes. Refactored services related to security to be in their package in /service package.
Copy link
Contributor

@VladoKat VladoKat left a comment

Choose a reason for hiding this comment

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

Apart from the comments, here, please change passwords to be char arrays instead of Strings. Let me know if it turns out to be too much of a hassle.

Copy link
Contributor

@VladoKat VladoKat left a comment

Choose a reason for hiding this comment

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

Looks good!

@sonarcloud
Copy link

sonarcloud bot commented Oct 5, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

89.3% 89.3% Coverage
0.0% 0.0% Duplication

@VladoKat VladoKat merged commit 687c066 into test Oct 5, 2023
4 checks passed
@VladoKat VladoKat deleted the feature-19-user-authentication branch October 5, 2023 14:23
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.

2 participants