Allow Specifying redirect URI

[kevincox]

Right now the redirect URI is "hardcoded" to the current page. (Unless you are cordova) This is very inconvenient as oauth providers such as Google restrict the redirect URI to an exact hardcoded path. This effectively means that you must run the login widget from one of the pages that you have whitelisted. Note that this is at odds with how the remotestorage-widget works that will trigger a login flow on any page.

Example use case:

• User goes to /item/4298.
• In order to see that item they need to log in.
• This is an error because the redirect URI is not /item/4298.

I have a hacky workaround here:

import RemoteStorage from "remotestoragejs";
import * as store from 'svelte/store';

import RecipeDb from "./db.js";

class MyRemoteStorage extends RemoteStorage {
	authorize(options) {
        // Mostly copy-pasted from the super method.

		this.access.setStorageType(this.remote.storageApi);
		if (typeof options.scope === 'undefined') {
		  options.scope = this.access.scopeParameter;
		}

        // Note that in order to direct the user back to the page they started the login from I need to save the original path.		
		let uri = `${location.pathname}${location.search}${location.hash}`;
        // Then I set the redirect URI to the dedicated receiver endpoint.
		options.redirectUri = `${location.origin}/oauth#!${encodeURI(uri)}`;
		
		RemoteStorage.Authorize(this, options);
	}
}

Note that there are two things to solve here.

1. Use a stable redirect URI.
2. Allow the app code to provide enough information to preserve state before login.

[raucao]

Allow the app code to provide enough information to preserve state before login.

It is actually possible to use the OAuth state parameter for this. I don't see this documented as public API for remoteStorage.connect(), so we may have to add this as an optional argument to the connect function. It could then also be added as config option to the widget add-on, so it calls connect with the correct arguments. The same could be done for the redirect URI. I think both are good additions.