-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Fix - Bypass unnecessary logs on logging out. #11479
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
Conversation
|
|
||
| @staticmethod | ||
| def _validate_cookie_params(session_id, user_id): | ||
| def _validate_cookie_params(session_id, user_id, from_logout=None): |
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.
should this default to False?
|
jenkins run quality |
|
lgtm 👍 ; after tests pass |
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.
Can we consider an alternative implementation that doesn't require passing a usage-specific is_from_logout boolean parameter around? I would like to keep this module from not having a baggage of booleans passed around (per Clean Code book etiquette).
One idea: create a context manager for controlling the logging in this middleware. And then, when is_from_logout is true, set the logging context manager logging level to Error: logging.basicConfig(level='logging.ERROR')
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.
Also, are you disabling the following log message as well? I didn't see the code for that.
middleware.py:371 - SafeCookieData user at request '5' does not match user in session: 'None'
We would need to change it to a Warning level instead of an Error level - since it's an expected case for logouts.
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.
@nasthagiri Its being skipped here. Setting the logging level is a great idea, I will be doing that! I have to change the specified log to warning level as well.
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.
Ah. Thanks. I now see there were 2 logs within the same if statement. Thanks.
365dbfe to
ae3f7f2
Compare
|
@nasthagiri may you please take a look. Thanks! |
|
|
||
| finally: | ||
| if logger.getEffectiveLevel() == ERROR: | ||
| logger.setLevel(INFO) |
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.
hmm.. is there a way to determine what the original logging level was so it gets reset back to the original value. Here, we are assuming that it was configured to INFO. But that may not always be the case.
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.
Actually, I have confirmed while debugging, this was set to INFO when got from getLogger(__name__) by default.
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.
If that's not feasible we can store the original logging level after getting logger through getLogger(__name__) to restore back later?
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.
I believe you should be able to retrieve the original logging level by calling getLogger(__name__).getEffectiveLevel.
|
Thanks @Qubad786. Looking better. A few more comments. |
| the request is from logout. | ||
| """ | ||
| if _is_from_logout(request): | ||
| logger.setLevel(ERROR) |
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.
sorry, why do we want to log this as an error? Don't we not want to log this at all?
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.
The idea was to increase the threshold of our logging level from WARNING to ERROR. This way, only actual errors get logged in the logout case, and not expected warnings.
2554509 to
79e42f1
Compare
|
@adampalay , @nasthagiri please have a look. Thanks! |
| has 'is_from_log_out' attribute set to true. | ||
| """ | ||
| response = self.client.get(reverse('logout')) | ||
| self.assertEqual(getattr(response.wsgi_request, 'is_from_logout', False), True) # pylint: disable=no-member |
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.
You can use self.assertTrue too
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.
Agree. assertTrue will give a better error message when it fails.
|
👍 from me |
|
👍 awesomeness. thanks! |
79e42f1 to
faf3a64
Compare
|
jenkins run bokchoy |
Fix - Bypass unnecessary logs on logging out.
…at the user/session change is expected
This is intended to silence a rare false positive that seems to happen when someone logs in on a browser that already has an active session for another user. We believe there should be no further positives once this case is handled. - login and logout views annotate the response to indicate the session user should be changing between the request and response phases - safe-sessions middleware skips the verify-user check when this annotation is present Also: - Adds a test around existing behavior for unexpected user-changes - Remove logging control based on `is_from_log_out`. This reverts most of af9e26f/PR #11479 for two reasons: - The safe-sessions `_verify_user` code has since changed to check for `request.user.id == None` - A commit later in the PR changes the login and logout pages to signal that the user/session change is expected
PLAT-998
Background:
There were unnecessary warning and error logs when user legitimately logs out from LMS which were causing overall tracking logs noisy.
Fix:
I have fixed this by setting an attribute
is_from_logouttorequestobject in logout view and checking to see whether the response is coming from logout in safe session middleware.@adampalay, @mushtaqak Please have a look.
Thanks