-
Notifications
You must be signed in to change notification settings - Fork 45
AMM-1507 | Force logout not restricting access in Supervisor module #205
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
AMM-1507 | Force logout not restricting access in Supervisor module #205
Conversation
WalkthroughThe Changes
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
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.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/main/java/com/iemr/common/controller/users/IEMRAdminController.java
(1 hunks)
🧰 Additional context used
🪛 ast-grep (0.38.1)
src/main/java/com/iemr/common/controller/users/IEMRAdminController.java
[warning] 927-927: The application does not appear to verify inbound requests which can lead to a Cross-site request forgery (CSRF) vulnerability. If the application uses cookie-based authentication, an attacker can trick users into sending authenticated HTTP requests without their knowledge from any arbitrary domain they visit. To prevent this vulnerability start by identifying if the framework or library leveraged has built-in features or offers plugins for CSRF protection. CSRF tokens should be unique and securely random. The Synchronizer Token
or Double Submit Cookie
patterns with defense-in-depth mechanisms such as the sameSite
cookie flag can help prevent CSRF. For more information, see: [Cross-site request forgery prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Req\ uest_Forgery_Prevention_Cheat_Sheet.html).
Context: response.addCookie(cookie);
Note: [CWE-352] Cross-Site Request Forgery (CSRF). [REFERENCES]
- https://stackoverflow.com/questions/42717210/samesite-cookie-in-java-application
(cookie-missing-samesite-java)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: style-check / checkstyle
- GitHub Check: Build
- GitHub Check: Package-test
- GitHub Check: Analyze (java)
🔇 Additional comments (2)
src/main/java/com/iemr/common/controller/users/IEMRAdminController.java (2)
896-910
: LGTM! Well-structured logout implementation.The method correctly:
- Calls the service layer to perform logout logic first
- Invalidates JWT cookies after successful logout
- Handles exceptions properly with appropriate error responses
- Maintains consistent response format
895-895
:✅ Verification successful
Verify API breaking change impact across the codebase.
The method signature change adds new parameters (
HttpServletRequest httpRequest, HttpServletResponse response
), which is a breaking change for any direct method invocations. However, since this is a REST endpoint, Spring will automatically inject these parameters, so HTTP clients should not be affected.Please verify that no internal code directly calls this method:
🏁 Script executed:
#!/bin/bash # Description: Search for direct method calls to forceLogout to ensure no breaking changes # Expected: Only REST endpoint usage, no direct method calls # Search for direct method invocations of forceLogout ast-grep --pattern 'forceLogout($$$)' # Search for any references to forceLogout method rg -A 3 '\.forceLogout\(' --type javaLength of output: 558
Breaking change validated: controller method signature change is safe
A search for direct invocations of IEMRAdminController.forceLogout found only the service call (
iemrAdminUserServiceImpl.forceLogout(request)
) in the same class—no calls to the controller method itself. Since Spring injectsHttpServletRequest
andHttpServletResponse
automatically, this signature change won’t break internal code or external HTTP clients.
src/main/java/com/iemr/common/controller/users/IEMRAdminController.java
Outdated
Show resolved
Hide resolved
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.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/main/java/com/iemr/common/controller/users/IEMRAdminController.java (1)
912-936
: Consider SameSite consistency with project CORS requirements.The invalidateJwtCookie implementation is well-structured and addresses previous security concerns. However, there's a potential inconsistency with the project's CORS configuration.
Based on retrieved learnings, this project uses
SameSite=None
for cross-origin requests. SettingSameSite=Strict
for invalidation might prevent proper logout in cross-origin scenarios.Consider using
SameSite=None
to maintain consistency with the project's CORS requirements:- cookie.setAttribute("SameSite", "Strict"); + cookie.setAttribute("SameSite", "None");Alternatively, if
Strict
is intentionally used for enhanced security during logout, consider adding a comment explaining this design decision.🧰 Tools
🪛 ast-grep (0.38.1)
[warning] 927-927: The application does not appear to verify inbound requests which can lead to a Cross-site request forgery (CSRF) vulnerability. If the application uses cookie-based authentication, an attacker can trick users into sending authenticated HTTP requests without their knowledge from any arbitrary domain they visit. To prevent this vulnerability start by identifying if the framework or library leveraged has built-in features or offers plugins for CSRF protection. CSRF tokens should be unique and securely random. The
Synchronizer Token
orDouble Submit Cookie
patterns with defense-in-depth mechanisms such as thesameSite
cookie flag can help prevent CSRF. For more information, see: [Cross-site request forgery prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Req\ uest_Forgery_Prevention_Cheat_Sheet.html).
Context: response.addCookie(cookie);
Note: [CWE-352] Cross-Site Request Forgery (CSRF). [REFERENCES]
- https://stackoverflow.com/questions/42717210/samesite-cookie-in-java-application(cookie-missing-samesite-java)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/main/java/com/iemr/common/controller/users/IEMRAdminController.java
(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
src/main/java/com/iemr/common/controller/users/IEMRAdminController.java (1)
Learnt from: sandipkarmakar3
PR: PSMRI/Common-API#162
File: src/main/java/com/iemr/common/utils/CookieUtil.java:40-47
Timestamp: 2025-02-21T07:42:36.497Z
Learning: In the Common-API project's CookieUtil class, JWT cookies are configured with SameSite=None to support cross-origin requests, which is required for the project's CORS functionality.
🪛 ast-grep (0.38.1)
src/main/java/com/iemr/common/controller/users/IEMRAdminController.java
[warning] 927-927: The application does not appear to verify inbound requests which can lead to a Cross-site request forgery (CSRF) vulnerability. If the application uses cookie-based authentication, an attacker can trick users into sending authenticated HTTP requests without their knowledge from any arbitrary domain they visit. To prevent this vulnerability start by identifying if the framework or library leveraged has built-in features or offers plugins for CSRF protection. CSRF tokens should be unique and securely random. The Synchronizer Token
or Double Submit Cookie
patterns with defense-in-depth mechanisms such as the sameSite
cookie flag can help prevent CSRF. For more information, see: [Cross-site request forgery prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Req\ uest_Forgery_Prevention_Cheat_Sheet.html).
Context: response.addCookie(cookie);
Note: [CWE-352] Cross-Site Request Forgery (CSRF). [REFERENCES]
- https://stackoverflow.com/questions/42717210/samesite-cookie-in-java-application
(cookie-missing-samesite-java)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Analyze (java)
- GitHub Check: Package-test
- GitHub Check: Build
🔇 Additional comments (1)
src/main/java/com/iemr/common/controller/users/IEMRAdminController.java (1)
895-910
: LGTM! Method signature properly updated for cookie invalidation.The forceLogout method has been correctly updated to accept HttpServletRequest and HttpServletResponse parameters, enabling proper JWT cookie invalidation. The implementation follows a clear sequence: perform logout logic, invalidate cookies, and return success response with appropriate error handling.
|
Merge pull request PSMRI#205 from srishtigrp78/feature/version/upgrade
📋 Description
JIRA ID:
AMM-1507 | Force logout not restricting access in Supervisor module
Please provide a summary of the change and the motivation behind it. Include relevant context and details.
✅ Type of Change
ℹ️ Additional Information
Please describe how the changes were tested, and include any relevant screenshots, logs, or other information that provides additional context.
Summary by CodeRabbit