I think the best solution would be to communicate this through the UI, for instance by visually connecting corresponding PDF and answer sections (e.g. by placing them into the same box).
EDIT: I think it would be quite nice in general to group these corresponding sections together visually.
Well the above example couldn't really happen since after the PDF section containing the question there would already be an answer section.
But I agree that it's a small thing, let's keep this on nice-to-have for the time being.
I think the migration should work, since I can't think of an instance where we would have an answer section without a visible PDF section.
As for [2], I see your point in the sense that the answer- and PDF-section are visually disconnected, but from a usability perspective there will hardly ever be a case where an answer section will be displayed but the corresponding PDF section will be hidden. Let me know what you think the intended behaviour should be!
I see, then it's not necessarily a bug but rather an inconvenience on two levels:
Old exams now show many empty answer sections like this. This could be resolved by running the migration, I assume.
When hiding new sections, the answer section still needs to be hidden manually. This could be alleviated by hiding the associated answer section when a cut is hidden. Just a quality of life upgrade.
It used to be the case that answer sections of hidden cuts were automatically hidden, but it seems like this behaviour has changed.
To me, the expected behaviour is that answer sections of hidden cuts are automatically hidden (or at least hidden by default).
The above behaviour is intended, but it would be nice if the answer section associated with a PDF section would automatically be shown/hidden along with its PDF section, while still being controllable independently if desired.
Due to implementation details in the way that keycloak is integrated with Switch (by protecting the login endpoint using the switch apache auth proxy) check-sso doesn't work correctly iirc and simply performs a normal login redirect.
Right, that kinda sucks. A hotfix could involve manually remembering with localStorage whether the user is currently signed in and only redirecting if they are.
it wouldn't quite be as easy as integrating a library because we'd need some metadata on the client as well: It would be important to know on the client-side when the token expires so that the FE can send a request which refreshes the token.
The implementation we used for mugs was a pre-existing OAuth2 adapter (Passport.js in conjunction with a custom OAuth2 strategy), which works since OIDC is based on OAuth2, but I'm not sure what the implications are of doing it that way.
I'm not sure I'll find the time to take a crack at this, considering I haven't booted up the code in probably a year. But if I do, I'll probably first try to get a hotfix working, something along the lines of what I outlined above.
In the long term, a robust solution might involve SSO authentication over the backend, which can then issue access- and refresh-tokens to the client using httpOnly-cookies. IIRC, this is the solution we used for the Tassenpranger.
I see. I agree that as a user it's nice to have 1 login for all VSETH services, but having a persistent session is definitely more important to me and I'd argue to most users.
As far as I understand, currently the silentCheckSso option relies on third-party cookies, which are already being blocked by some browsers, correct? If this is the case, there most likely won't be a fix for that in the near future as more and more browsers start to completely disable third-party cookies by default (Safari already does so and Chrome is soon to follow).
Non-silent check-sso
could be a short term solution (and definitely more usable than just having to log in every time the page refreshes), but would presumably come at the cost of increased initial load time. This would be a worthwhile tradeoff in the short term, IMO.
It seems to me (without being very familiar with the code base, especially not anymore), that since we actually have a backend, using httpOnly cookies together with a refresh token would be the preferred solution.
Making the persistent storage of tokens optional (with opt-out) would be a good compromise from a usability perspective, as an average user would most likely care more about the improved convenience over the diminished security. I think this would still be preferable over the current solution.
I need to re-login after each page refresh, which is a pretty big inconvenience. This seems to be the case for the majority of people I've spoken with, so it's probably a bug.