Redirect user when loading class summary results in 403 #12755
Conversation
github-actions
bot
added
APP: Coach
| // done to gracefully handle the case that an admin is signed out due to | ||
| // timeout while in Coach and when a Learner signs in, they are returned | ||
| // to the URL the admin was previously on and hit this 403 | ||
| redirectBrowser(); |
There was a problem hiding this comment.
This is not fixing the issue as described - the mismatch in the behaviour was specifically in the quiz creation page, where it is not using the authentication wrapper component to show meaningful errors to the user in the case that they are not authenticted.
Also, as this is now applying to every page in coach, the existing authentication wrapper errors may not show because of this.
Further, if a coach's session expired, and the classSummary API update call returned early, they would now get redirected to the login page, but without a next parameter to guide them back to where they were before.
Build Artifacts
|
marcellamaki
modified the milestones:
Kolibri 0.17: Planned Patch 2,
Kolibri 0.18: General maintenance
nucleogenesis
force-pushed
the
0.17--quiz-routing-auth-error
branch
from
b11c898 to
c8a6c37
Compare
|
Learner is still being stuck with blank page and 403 in the console 😕 PR-12755.mp4 |
|
Hrm, looks like it's maybe a race condition? If the class notifications endpoint gives a 403 before the class summary endpoint, we see it stuck, but if the class summary endpoint returns then we see the authentication message properly? |
…uthmessage w/ urls
…g even if an error occurs mid-navigation (for example, like in QuizSummary's beforeRouteEnter)
nucleogenesis
force-pushed
the
0.17--quiz-routing-auth-error
branch
from
63243b0 to
3eaa320
Compare
|
@radinamatic I've updated this PR and tested in coach - the learner user should be navigated to the AuthMessage as expected now. |
|
Hi @nucleogenesis - I confirm that #12442 is fixed. |
| .catch(() => { | ||
| // We catch here because `handleApiError` throws the error back again, in this case, | ||
| // we just want things to keep moving so that the AuthMessage shows as expected | ||
| next(); |
There was a problem hiding this comment.
This may end up calling next twice, because we catch and then then - but I don't think this matters.
There was a problem hiding this comment.
I think calling next() basically stops any further code execution so if one promise rejects at any point, we'll have next called and will be redirected altogether.
That said, I did look back at Promise.all's docs and see that in this case, the then would be called if next wasn't called because of the chaining order.
If the then comes first in the chain series, then it would not be called if the catch blocks ran because Promise.all handles any rejection immediately. But, if you catch errors and chain a then to the catch though, the then is run.
Might be misinterpreting a bit there but seemed to be the case when I played around a bit w/ Promises in the terminal
In any case, I think you're right that it won't have any effect as-is.
| this.loading = false; | ||
| this.$store.dispatch('notLoading'); | ||
| try { | ||
| this.$store.dispatch('handleApiError', { error }); |
There was a problem hiding this comment.
Should we only put the handleApiError call in here, so that the other two lines get executed?
There was a problem hiding this comment.
Updated here, thanks Richard
Summary
When a coach is doing coach things and they are logged out due to timeout, Kolibri will keep track of the last place the user was in. If a coach is doing coach things, then they timeout, but then a Learner logs in again the Learner is redirected to where the coach previously was.
Since the Learner cannot do Coach things, they get a
403on the classSummary API call.So we catch that particular error and redirect the user such that they go to wherever they'd normally have gone after logging in.
References
Fixes #12442
Reviewer guidance
kolibricookie, see that you are redirected to the sign-in pageBefore the fix:
After the fix:
completelyvirtually unaware that they were initially being redirected to Coach things (unless they're keenly watching the URL bar or their devtools as they are still directed to the Coach URL before being re-redirected)Testing checklist
PR process
Reviewer checklist
yarnandpip)