Alternative, better mechanism for authenticating user than --root

[simonw]

This is partly an alternative to #36 where I wanted to share cookies between multiple BrowserWindow instances.

But also... I don't like using --root because it turns on a bunch of confusing tools that are usually intended for debugging. Instead I think datasette-app-support should provide a mechanism for signing the user in as "id": "datasette-app" - then I can use custom permissions to enable things like datasette-upload-csvs without turning on debugging menus for the root user.

[simonw]

The plugin could set its own random secret (equivalent to how --root works) and then support a /-/auth-app-user?token=xxx&redirect_to=/-/plugins URL which the shell could then use when opening new windows - e.g. for the "list installed plugins" menu option.

[simonw]

For the moment I'm going to lock this down so that it's only visible to the current, authenticated use from localhost - but in the future it might be good to have an option for sharing your data by running the server attached to 0.0.0.0 so you can share links with other people on your network.

[simonw]

#52 (option to expose server to other people on your network) makes this even more relevant.

I'm going to have a user account called "admin" (because "root" already does some things in the Datasette world, and as language it's less user-friendly than "admin") - the plugin will set a ds_actor cookie for it when a new browser window is opened.

[simonw]

Could even do this by calling a special API endpoint, /-/generate-admin-actor-cookie, which is authenticated using the mechanism introduced by #53 - and then setting the return value as that in a cookie when first instantiating the BrowserWindow.

[simonw]

Setting cookies from Electron code looks too complicated - I'll go with the simpler mechanism where every new BrowserWindow hits /-/auth-app-user?redirect=/-/plugins which accepts the Authorization: Bearer xxx token from #53 and redirects with the newly set cookie.

[simonw]

I'm going to need to refactor all of the places that create a BrowserWindow and load a URL in it to a new method on the DatasetteServer class which uses the new /-/auth-app-user endpoint - otherwise users could accidentally create windows that don't have the signed cookie.

One exception: this code, because it displays the loading.html screen before the server has started (so it can continue to display while pip install datasette etc is happening on first run).

datasette-app/main.js

Lines 185 to 208 in 9a8bf4e

	mainWindow = new BrowserWindow({
	width: 800,
	height: 600,
	show: false,
	});
	mainWindow.loadFile("loading.html");
	mainWindow.once("ready-to-show", () => {
	mainWindow.show();
	});
	postConfigure(mainWindow);
	portfinder.getPort(
	{
	port: 8001,
	},
	async (err, freePort) => {
	if (err) {
	console.error("Failed to obtain a port", err);
	app.quit();
	}
	// Start Python Datasette process
	datasette = new DatasetteServer(app, freePort);
	const url = await datasette.startOrRestart();
	mainWindow.loadURL(url);

[simonw]

Here's how to pass the authorization: bearer xx header in a POST request to that API endpoint:

      newWindow.loadURL(`http://localhost:${this.port}/-/auth-app-user`, {
        extraHeaders: `authorization: Bearer ${this.apiToken}`,
        postData: [
          {
            type: "rawData",
            bytes: Buffer.from(JSON.stringify({ redirect: path })),
          },
        ],
      });

This wasn't obvious: the extraHeaders takes a string (headers can be separated by newlines) rather than a dictionary, and the postData thing was a very odd shape too.