Ability to fetch some configuration before logging in
Description
Environment
Potential Workaround
relates to
Checklist
hideTestRail: Results
Activity
Michal Kuklis August 9, 2017 at 12:03 PM
I don't know much about how the backend is structured but I like the separate module idea. It could be potentially used for other public things in the future. Another approach here could be to just make the locale configurable from stripes (in a similar fashion to the tenant).
Mike Taylor August 9, 2017 at 11:03 AM
Tenant-wide customisation like this could be hardwired into the JS bundle that we generate for the tenant; or (more elegant, I think) it could be determined by tenant-level configuration information drawn from mod-configuration.
But when you ask "how is this handled?" (as in, today) the answer is "it's not". That is part of what we're designing here and now
shale99 August 9, 2017 at 11:00 AM
a question - i may be off with this, but - i assume a tenant may want a custom login screen (with the institution's logo? whatever...)
how is this handled? - and can a default locale be handled in the same way for the institution - after initial sign-in by the user belonging to that tenant - they can configure a default language and this is saved locally (cookie, or something) for pending login attempts (requests for the login screen and then be accompanied by the preferred locale
Mike Taylor August 9, 2017 at 10:14 AM
Not sure why we would need an entirely new module? Possibly, just an endpoint with no permissions for reading selected values.
What I am referring to is a module with no functionality (apart from request filtering and pass-through) which would exist only to furnish the necessary module-permissions to the module doing the real work.
One could easily imagine such a module existing in a form that is configured by a separate file, and deploying it as a front-end for many different "real" modules, as mod-anonymous-configuration, mod-anonymous-users, or whatever we found we needed. It seems like a good general-purpose mechanism that uses what we already have an needs minimal additional work.
yes, it's technically possible to have endpoints that require no authentication (no authorization can be of course allowed by not setting any permissions). But I don't think we should allow it – there are reasons for wanting to track who is using a service, even if the service is open/require no permissions (audit, logging, etc).
Sure – but the issue here is to do with accesses when there is no user. As in the motivating example of deciding what locale to use when presenting the login screen.
Jakub Skoczen August 9, 2017 at 9:39 AM
Not sure why we would need an entirely new module? Possibly, just an endpoint with no permissions for reading selected values.
Still, referring to what Heikki said earlier – yes, it's technically possible to have endpoints that require no authentication (no authorization can be of course allowed by not setting any permissions). But I don't think we should allow it – there are reasons for wanting to track who is using a service, even if the service is open/require no permissions (audit, logging, etc).
Details
Details
Assignee
Reporter
Mike TaylorPriority
P3
, to do with establishing the locale for Stripes, raises a more general problem.
We fetch the locale from mod-configuration, which needs an Okapi authentication token so that it can establish whether the necessary permissions are associated with the user. (But also because we might well want to get a user-specific locale – for example, a Spanish-speaking student at a primarily anglophone Texan university might prefer a Spanish-language FOLIO.)
But we also need the locale before login – for example, so we know what language we should present the login message in. So we need the ability to query the configuration module both without and with logged-in user.
I'd welcome thoughts on how we might achieve this this: allowing non-logged-in access to (at least some of) mod-configuration, but without losing the option of doing user-specific mod-configuration options such as fetching a per-user locale after login. For example, might we change mod-configuration so that certain properties – e.g. those with moduleName=GLOBAL – can be searched for and fetched with no permissions?
I am filing this in the high-level FOLIO project because it's a cross-cutting issue with implications for the UI, the configuration module, and perhaps also for Okapi and the permissions system.