refactor: bad sgid session returns 400 instead of 500 #2249
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jia1
approved these changes
Feb 23, 2024
I think it is more likely a result of the jumping between SIS and the machine itself. This only happens on GSIB so likely not a SGID issue. Since this doesn't impact the user's ability to log in, probably not worth pursuing. |
KishenKumarrrrr
had a problem deploying
to
staging
GitHub Actions
Failure
KishenKumarrrrr
deleted the
refactor/return-http-400-for-sgid-bad-session
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Since Feb 8 2024, the
POST /login/sgidendpoint is called twice whenever a user attempts to log in via a GSIB device. One of the API calls is made withoutreq.session.sgidset and thus fails in the BE and results in a HTTP 500 being returned.However, this HTTP 500 does not affect the user's ability to log in and is not reflected in the network tab of the developer console as well. Thus, the impact of this issue is low. Instead of returning a HTTP 500, we are choosing to downgrade the error to a HTTP 400 instead to reflect the seriousness of the issue.
Our current hypothesis is that this second call is made by SIS instead of our FE due to
*.postman.gov.sgbeing whitelisted on SGProxy but the SGID URL having to go through SIS. The emergence of this issue also nicely corresponds to the date we whitelisted*.postman.gov.sgwhich lends credence to the hypothesis.