Multi domain token usage #9791
Multi domain token usage #9791
Conversation
packages/ecs/src/Engine.ts
Outdated
| @@ -49,7 +57,7 @@ export class Engine { | |||
| const UndefinedEntity = bitECS.addEntity(HyperFlux.store) | |||
| } | |||
|
|
|||
| api: FeathersApplication<ServiceTypes> | |||
| api: FeathersClient | |||
There was a problem hiding this comment.
we shouldn't overload this here, since we access it on the backend and it will have different types
There was a problem hiding this comment.
we should be able to declare a type override in client-core that will only be applied in packages that import client-core
There was a problem hiding this comment.
Weird, I made this change because of type errors when I started, but maybe something has changed in dev since then, because now it's not showing any type mismatches when I revert to what it was.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| @@ -97,7 +97,11 @@ export const configurePrimus = | |||
| const origin = [ | |||
| 'https://' + appConfig.server.clientHost, | |||
| 'capacitor://' + appConfig.server.clientHost, | |||
| 'ionic://' + appConfig.server.clientHost | |||
| 'ionic://' + appConfig.server.clientHost, | |||
| 'https://cool.pants.com', | |||
There was a problem hiding this comment.
Left over test domains? We should probably remove capacitor & ionic stuff too
packages/server-core/src/networking/allowed-domains/allowed-domains.class.ts
Outdated
Show resolved
Hide resolved
barankyle
force-pushed
the
multi-domain-token-usage
branch
3 times, most recently
from
9ddd052 to
6561bc3
Compare
barankyle
force-pushed
the
multi-domain-token-usage
branch
3 times, most recently
from
3e4fcf0 to
afbd7af
Compare
For multi-domain setups, having to log in on each different domain is annoying. This saves the user's login information in the 'root' domain of the deployment, and on all domains sources the login credentials from an iframe running in the root domain using postMessage. This only gets skipped if a user has expressly denied cross-domain sharing of their login information, in which case localStorage will be used as the source for login credentials. The iframe loads a new non-vite page in client/public, and does so in the root domain. Some user authorization flow is required on most browsers to enable this, using the requestStorageAccess API. A new backend service, allowed-domains, takes in a domain on a query paramter and returns true if that domain is part of the deployment, and a 204 if not. By default this just returns the root domain, but this is extensible via projects' hooks to add other domains to the allowed list. It can also just be passed a variable isAllowed from a hook if fetching all domains would be cumbersome, and simply querying whether the domain is in a table would be simpler. The accessor iframe uses the response to determine whether to even attempt to access the cookies or prompt the user with requestStorageAccess.
barankyle
force-pushed
the
multi-domain-token-usage
branch
from
afbd7af to
af080a2
Compare
|
Note to myself, something about the cookie seems to mess up OAuth login on the root domain if it becomes disconnected from a database user. Locally, I'd reinited the database several times while the cookie was still on localhost:3000, and it broke all OAuth providers. The |
Summary
References
closes #insert number here
QA Steps