eclipse-ditto
Select Ditto Explorer UI "environment" via query parameter
For the Ditto Sandbox (for example) it would be really helpful if one could provide a query parameter when opening the Ditto Explorer UI specifying which "environment" to use.
A similar feature is possible for Swagger-UI where you can define multiple "definitions" (OpenAPI specs the Swagger-UI should show in its dropdown) and specify the initial one to load via a query parameter.
Swagger-UI describes its options here (urls and urls.primaryName are the ones I thought about).
Maybe it's worth thinking about whether the Ditto UI "templates" should also be available (and referencable) as separate files on a webserver similar to Swagger-UI urls.
@thfries what do you think about this?
First of all: yes, I am also annoyed to need to select the right environment all time 😉
The solution in my mind was to store the last environment of a user in the browser cache - like with all other user specific settings. The Swagger-UI solution looks powerful. So you are thinking to allow to configure all environments and the default environment from outside? Interestingly enough Swagger does not save any user or browser specific data.
I think a user should be able to change his personal settings directly in the UI. A way to share the settings of one user with others is also very useful, but I don't see spontaneously a way to combine both approaches (one idea was to store the environment configuration in a thing for each environment but that is another completely different approach).
You see, I am a bit confused now. Need to think about it and some further discussion would be helpful, too. Thanks.
Some more thoughts (hope I am not overcomplicating things):
- The environment templates should be moved to the templates folder (they are currently in the environments.js)
- The environment templates are loaded only the very first time on one browser instance. As soon as a user does any change on any environment (e.g. just authenticates), all environments are taken from the browser store. You will never get an update on the templates again until you clear your browser cache. That is not good. At least each of the environments should be stored independently
Next to that an environment stores different types of data:
- environment configuration itself (url, solutionId, namespace, ditto-version, etc.): not user specific, should be shared
- Authorization header (to switch the headers when you switch the environment): should NOT be shared.
- Fieldlist: the field definitions should be shared with others, while the selection and order of columns is user specific
- Filterlist: user specific but may also be shared
- pinned things: very user specific
- Message Templates: similar to field list, these are not user specific
So as a first solution idea:
- Separate 1 from 2 - 6
- 1 can be configured via url parameter:
-
environmentsURL-> link to a json with all environments. If not given, the file from templates folder will be used -
primaryEnvironmentName-> as desired - can not be changed by the user
-
- 2 - 6 will still be stored per browser (referring with the environmentName)
- A user can create additional environments that are stored per browser
What is missing:
- "my last environment" stored in the browser cache. We could still do that and just override the primaryEnvironmentName?
- All environments are still in one json - so no way to specify
environmentURLs - A possibility to share 3,4 and 6 (similar like in Jira or Postman)
- 2 should be handled by the browser pw manager (Chrome is giving a warning there). Don't know the details here.
I like where your thoughts are headed to.
My thoughts regarding the shared vs. local environments:
- maybe a user "modified" environment can "link to" the URL of the environment it was created from
- and a user modified environment could overwrite any fields/config from the shared environment
- the 2 environments ("shared" and local from browser storage) are merged with the local one having precedence
- that way, changes to the "shared" environment could be applied, if not explicitly overwritten
Regarding storing the authentication information in the local storage: I think we must rethink that ... I did not think about this previously, but this raises some security concerns.
The local browser storage can be accessed by every other webapp running on the same domain, right? So for the Ditto-UI deployed on "eclipse.github.io/ditto" this would mean that each other GitHub pages web-app can access them (similar to cookies).
It's ok when the browser wants to store the credentials - via the browser mechanism. But the Ditto UI should not persist credentials by itself.