[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:
Relates
relates to STCOR-51 Select a Translation Library for the ... Closed
Sprint:
Development Team: Core: Platform

 Description   

STCOR-51 Closed , 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.



 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 ]

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.

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...)
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

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).

Generated at Thu Feb 08 23:08:10 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.