Open galfert opened 7 years ago
One idea would be to always use document.location.origin
instead of document.location.href
for the redirect URL. And then also introduce an option to manually configure the redirect URL when instantiating the remoteStorage
instance. I guess that is needed to allow for apps that don't have their own domain but e.g. are served from a sub-directory.
Anything I'm missing here or any other ideas?
You could of course add other potential routes (e.g. /settings
if you connect from there) to your app config at Google. And this can also be an issue if your RS server is strict about specific URLs vs. just the origin at 5apps for example.
Hosting apps in subdirectories is not a good idea, because they will share the local storage, as well as permissions. We should never encourage that in my opinion.
I don't have a strong opinion on this yet, but I'd also try not to require developers to always have their app's root URL shown after a connect in the default situation.
You could of course add other potential routes (e.g. /settings if you connect from there) to your app config at Google. And this can also be an issue if your RS server is strict about specific URLs vs. just the origin at 5apps for example.
That would be really cumbersome if you have a lot of different URLs or even impossible if your app has dynamic URLs.
I don't have a strong opinion on this yet, but I'd also try not to require developers to always have their app's root URL shown after a connect in the default situation.
Another way could be to keep the default to use document.location.href
, but allow to override that by defining a specific redirect URL option.
Just FYI: I removed the bug label, because this is not a bug in the code here, but more of an issue of a potentially missing config option/argument, as well as the provider OAuth requirements.
Google is automatically expiring the authentication tokens after a while. Our Google Drive client is already handling this by re-authorizing the app when getting a 401 response from Google.
I noticed a problem with this behavior though when the user is on a different URL than what had been configured as the allowed redirect URI. The client always uses the current URL as the redirect URI, which results in a Google 400 page with the error