rawnsley
commented
1 year ago The root of the authentication problem is this common theme: the admin pages are assumed to be co-origin with the hubs client pages and expect to be able to access localStorage for things like credentials.
An ugly workaround for this is to copy-and-paste the settings from the client to the admin pages, based on this method:
From the client page: JSON.stringify(localStorage);
Then right-click copy the result using Copy string as Javascript literal (Chrome option)
Then paste into the admin pages like this: Object.assign(localStorage,JSON.parse(_settings-string_));
Suggestions welcome on something a bit less hacky.
keianhzo
I've got the normal client pages working and connecting fine, but I'm having problems with the admin pages, which I've never actually got running locally outside of docker, so perhaps I'm missing a few key steps.
The first problem is that it can't read the schema.toml file because it appears to be expecting the hubs server to be providing it on the same port (as it does in production), but in this development environment the admin pages are hosted on hubs.local:8989 and the hubs pages are hosted on hubs.local:8080. It's possible the implications of this failure are just cosmetic.
The second problem is that the page doesn't seem to be recognizing that I'm signed in with any sort of credentials, despite the sign in process working fine on the hubs pages. It appears that store.state.credentials is blank for reasons unknown.
When the credential check fails, it once again falls back on the assumption that hubs is co-hosted on the same port for the redirection, which fails. This isn't really an issue that needs addressing though.
Sorry for spamming the issues today, but this new docker-compose is exactly what I've been wanting for ages and I'm very excited to dive in :-)