error page for samlLogin internal server errors
Currently any SAML error on POST /primo_library/libweb/samlLogin results in internal server error response (HTTP 500) and shows a corrupted paged from the old UI (see attachment)
Please implement a SAML NUI error Page for these types of errors including the SAML Error description which is currently only written into library_server.log files, e.g.:
2019-09-17 08:36:39,773 ERROR [t-ajp-bio-7701-exec-19] [c-Saml20MessageValidators] [O -(540627545,1652141697,null)] - SAML failure: This reponse samlSessionId does not match ours
2019-09-17 08:36:39,773 ERROR [t-ajp-bio-7701-exec-19] [c-SAMLLoginServlet] [O -(540627545,1652141697,null)] - SAML failure: Response was not verified
Event though the end user may not understand the technical details, theses SAML messages are at least a hint what is going wrong.
Ulrich Leodolter
shared this idea
-
Stacey van Groll
commented
There has been some display and defect improvement in November 2022 Primo Release, with partial association to my case 05299251.
There was a defect fixed where the the email provided was admin@primo.com, instead of being taken from our E-Mail Addresses mapping table.
And the styling has also been improved. -
Stacey van Groll
commented
We are seeing this issue more recently in scenarios where users are logging in, and also when they use the browser back button after routing via silent login through SSO SAML.
I've opened a case to ask for help, if not with the best case scenario of resolving the error, then at least with improving the terrible dead end error page.
I've been advised as follows:
"Product management has indicated in the past that it is considered an enhancement request. The reasoning is that users are not meant to see the page unless there is an actual problem (such as a SAML misconfiguration), in which case the issue itself is addressed rather than the page.
I understand your situation is a little different, with the page showing up occasionally even though SAML is set up properly. However, not having been able to reproduce this ourselves, I'm afraid we will need a step-by-step scenario representative of a typical use case that can replicate the issue consistently (or at least with high probability) in order to regard this as different from the other cases."
We can replicate the issue consistently from console by opening from SSOService, which is expected to fail as single use, but there is no sign of why users are sometimes directed to end at this single use 200 and in others they are routed correctly.
It is frustrating to receive no further support because an issue cannot be replicated every single time by 'natural' use, but can be replicated consistently by console.
The argument for not fixing the error page to be more meaningful could also be made for any error page ie no-one is "meant" to see an error page.
Ex Libris should fix so that we may support our users better than this when they do occur.
