[FOLIO-765] Ability to fetch some configuration before logging in Created: 09/Aug/17 Updated: 18/Jan/19 |
|
| Status: | Open |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Mike Taylor | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 1 hour | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||
| Sprint: | |||||||||
| Development Team: | Core: Platform | ||||||||
| Description |
|
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. |
| Comments |
| Comment by Jakub Skoczen [ 09/Aug/17 ] |
|
I'll repeat my comment from STRIPES-447: Would fetching the "locale" information DURING login (as part of the login response) be enough? This can be done in mod-users-bl and would be aligned with the future direction for FOLIO (where locale can be set both on the tenant and user level). I am not in favor of a solution where we loosen (or circumvent) permission mechanism to fulfill specific use cases. |
| Comment by Mike Taylor [ 09/Aug/17 ] |
|
Nice idea, but in general we need configuration before we log in – for example, to choose the language of the Login page. I agree that loosening the permission model for a specific case is unappealing. But it doesn't seem unlikely that we will find other such cases down the line. Perhaps what we really need at this stage is a solid model for permissionless operations in general. (After all, we already have a class of special permissionless requests – /_/proxy/modules, for example.) One approach would be to have a new module, mod-anonymous-configuration, which simply has the relevant mod-configuration permissions in its module permissions, and which carefully forwards a well-defined subset of requests to the underlying mod-configuration. |
| Comment by Jakub Skoczen [ 09/Aug/17 ] |
|
We are closing the gap on /_ with the concept of "internal module" so all endpoints will be subject to permission checks (this will allow to reden okapi-console as a standard FOLIO app for example). I think we can agree that there is some tenant-level configuration that should be accessible to the UI immediately. Maybe it would make sense to "inject" that configuration into the UI bundle (since the bundle will be eventually generated per-tenant) during build? |
| Comment by Heikki Levanto [ 09/Aug/17 ] |
|
Hmm, as such there is not reason why a module could not serve requests without requiring the user to have any permissions. Such work all right without the user having logged in at all. That is exactly what happens with mod-login, the login request can obviously not have an auth token. Of course, when making a request without the token, you will have to pass the X-Okapi-Tenant header, so we know which tenant you are talking about. I understand the Stripes bundle has that information available, since it needs it for login requests. (As to the proxy/modules, some functions there will soon require permissions, as they well should. Just reading available modules should still be open for everyone, even without a token) |
| Comment by Mike Taylor [ 09/Aug/17 ] |
|
Yes, Stripes knows what tenant it is running for. Putting together that various things that have been said here, it seems like my suggestion of a mod-anonymous-configuration module proxying a subset of requests to mod-configuration may be the way to go: I think it will work without needing any changes to underlying code, and it makes use of existing mechanisms for eliding the permission requirements. |
| Comment by Jakub Skoczen [ 09/Aug/17 ] |
|
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). |
| Comment by Mike Taylor [ 09/Aug/17 ] |
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.
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. |
| Comment by shale99 [ 09/Aug/17 ] |
|
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...) |
| Comment by Mike Taylor [ 09/Aug/17 ] |
|
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 |
| Comment by Michal Kuklis [ 09/Aug/17 ] |
|
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). |