feat: access other instances#1002
Conversation
The purpose of this context is to hold information about a single instance of stoat (information that is currently stored in global configuration) Signed-off-by: Gtoasted <git@gtoasted.de>
Signed-off-by: Gtoasted <git@gtoasted.de>
Signed-off-by: Gtoasted <git@gtoasted.de>
…A_URL Signed-off-by: Gtoasted <git@gtoasted.de>
…Y_URL Signed-off-by: Gtoasted <git@gtoasted.de>
…BOX_URL Signed-off-by: Gtoasted <git@gtoasted.de>
Signed-off-by: Gtoasted <git@gtoasted.de>
…TCHA_SITEKEY Signed-off-by: Gtoasted <git@gtoasted.de>
Signed-off-by: Gtoasted <git@gtoasted.de>
Signed-off-by: Gtoasted <git@gtoasted.de>
Signed-off-by: Gtoasted <git@gtoasted.de>
Signed-off-by: Gtoasted <git@gtoasted.de>
don't know why the previous commits didn't Signed-off-by: Gtoasted <git@gtoasted.de>
Signed-off-by: Gtoasted <git@gtoasted.de>
Signed-off-by: Gtoasted <git@gtoasted.de>
|
Tbh I think this could be part of #997 to reduce the PR clutter a little. Good idea for how to handle it tho, but I think Also btw I made some changes to Instance.ts in my PR here. Created an InstanceManager to change Instances, but there are other ways to handle that. If it's part of the URL then it could be handled through the routes in index.tsx and switch via a call to |
|
Yeah, I wasn't sure if one monolitihc pr or multiple fine-grained pr's would be better. I'll see if can merge your changes and #997 into this pr later. You could just urlencode a colon if it comes to that, but I think some other form of configuration discovery (like a well-known uri) would be a better solution either way. As far as I know, navigate does actually support a base path, but it can only be supplied by the router component, so it would be static and therefore useless. If the url-based approach sticks, it would indeed require modifying all calls to navigate and a, but such is life. Maybe I could make wrapper tags for those, but I'm gonna hold out on such an endeavour until I know that it might actually get merged (or I get bored and do it anyway)). |
|
I don't really have the time to work on this further, and #999 looks promising, so I'll close this now. |
|
That's fine, your contributions were very helpful in laying the groundwork for the multi instance features |
Building on #997, I am currently implementing token federation. Currently, it is possible to prepend any path with /instance/hostname to instruct the client to access the instance at https://hostname, provided the api is located at https://hostname/api. My plan is to wrap all links in the instance.href function, so that they point to the path with the correct instance prefix. This should provide a basis to implement things like token federation or account switching across instances, as per #999.
As always, feedback would be greatly appreciated.