} else if (response.status === 403) {
var errorMessage = data.error && data.error.message ? stringAfter(data.error.message, ':') : unexpecetedError;
showError(errorMessage);
if(shouldRedirectToLogin(response)){
$rootScope.$broadcast('event:auth-loginRequired');
}
} else if (response.status === 404) {
However, this effectively narrows the times we can actually redirect to the login page to cases where the server actually returns a JSON data object with the message “HTTP Status 403 - Session timed out” all other cases will show the message:
There was an unexpected issue on the server. Please try again
Immediately one would think the status code 403 should actually be enough to trigger a redirection to the login screen but since additional work was done to narrow it down further it will be nice to understand what advised it.
Its very interesting that the code for 403-session timeout string check was explicitly added in that commit. I wonder why, since original code was exactly what you suggested. It says Mingle issue number: #2138. Unfortunately I don’t think we have access to that issue description.
Since the chances of device being offline for more time than the server timeout, all the POST requests can fail on sync back to server. So, any exception for 403 (Session timeout), should redirect to login page on the device and stop the push and pull process. The user has to login successfully again to initiate the process.
As per Wikipedia and HTTP standard seems 403 is for Forbidden (not authorised to access resource), but some servers are configured to return the same code for Forbidden and for Session timeout, and looks like the code was extended to handle such cases. But still the “hack” is brittle – checking for message string isn’t a good idea.
Unfortunately in the case of 401, there isn’t any special handling right now in code httpErrorInterceptor.js. It just shows the error message. Maybe in the case of 401 also Bahmni should redirect to login page?
So there could be a case where one wants to access a resource and wouldn’t be authorized by the server to do so, which therefore responds with 403, (same code as Session timeout).
I can’t think of a scenario is out-of-box Bahmni where someone would access a “forbidden” folder/resource.
It could occur if someone added a custom app into Bahmni UI, which allows someone to browse files on a web server, like xRays, patient PDFs, etc – and the web server throws a forbidden error if someone unauthorised tries to access it.
I feel like its best if Bahmni UI interprets the error codes and responds as HTTP expects. For Forbidden give an “Forbidden” message. For 401 give a session timeout/redirect to login. It shouldn’t do “more” than what the http error code says.