Open ableuler opened 5 years ago
There is a discussion in #676 to assign a specific service URL to the UI, e.g. https://<some-renku>/ui
- this looks a bit strange to me. Has there been any discussion in using e.g. https://entities.<some-renku>/datasets/:id
for example? Or is there a strong preference to use sub-paths instead of sub-domains? I could see getting wildcard DNS to be problematic for some deployments so maybe that's a point against. Then again, this could be a configurable property of the renku deployment and need not be hard-coded.
From today's discussion, we agreed to use URLs of the form [domain]/entities/[entity-kind]
e.g., http://renkulab.io/entities/datasets/
for the entity URIs. The argument for this is that the URIs that the user will most likely see are the URLs for the UI, and we want to keep these as simple as possible.
Two topics come to mind from today's discussion:
Upcoming or already existing Renku features make it necessary to re-think our URL patterns and the separation of concern between the gateway and our different backend services.
In an offline discussion during a Renku meeting we have agreed on the following 3 fundamental points:
Each resource is served entirely by one Renku backend service. This service might rely on other backend services to compose the necessary information. The gateway knows which backend service is responsible for serving a given resource and does the correct forwarding but it does not combine the information from different backend services.
Token-based authentication and authorization are in the responsibility of the backend services. The gateway authenticates the user based on the browser cookie and swaps the cookie for the corresponding backend API access token.
We use the simplest possible URLs as IDs for our entities, such as `renkulab.io/datasets/
Under these URLs we serve only redirection endpoints to the API or the UI, depending on the requested content type.
See also https://github.com/SwissDataScienceCenter/renku-gateway/issues/169 for a discussion on this topic.