Comment 2 for bug 1845243

OK... I looked into this and I think I know what's going on. As Jason observed, the token nested in the 'path' parameter isn't working for the serial console. And I think I found in the code why this is, the 'path' parameter is specific to noVNC and I didn't realize this before. :(

Here is the code where 'path' is parsed out of the query string and is then appended to the url which websockify will receive [1]:

        const path = readQueryVariable('path', 'websockify');

        // | | | | | |
        // | | | Connect | | |
        // v v v v v v
        status("Connecting");
        // Build the websocket URL used to connect
        let url;
        if (window.location.protocol === "https:") {
            url = 'wss';
        } else {
            url = 'ws';
        }
        url += '://' + host;
        if(port) {
            url += ':' + port;
        }
        url += '/' + path;

So, given a url for noVNC that looks like this:

  https://foo.com/vnc_lite.html?path=%3Ftoken%3Dfoo

because of the processing in vnc_lite.html, the url the websockify server receives looks something like this:

  ...?token=foo

without any nesting. And so the parsing works fine.

But, if you're running the serial proxy and there's nothing processing the 'path' variable, the websockify server receives the original url with the token embedded in the 'path' variable and will not parse it correctly.

There are two ways we could fix this, I think.

(1) Revert much of change I2ddf0f4d768b698e980594dd67206464a9cea37b and add the 'path' variable back *only* for noVNC console access url generation

or

(2) Add additional parsing logic to nova/console/websocketproxy.py to also look for a 'token' query parameter nested in a 'path' query parameter

It seems like the right thing to do is (1) but I will ask what others think before going forward with that approach.

[1] https://github.com/novnc/noVNC/blob/v1.1.0/vnc_lite.html#L155-L174