PWA feature - problem with Google Oauth authentication (and probably other similar systems)

[colinl]

PWA feature - problem with Google Oauth authentication (and probably other similar systems)

[colinl]

I have done some further tests and I am now sure that my initial analysis was correct. I have amended the description accordingly.

At the very least it would be helpful if there were a setting to disable the PWA feature so that a normal shortcut can be used to open the dashboard url.

[bartbutenaers]

@colin,
I am not a PWA expert, but I 'think' it is not as easy like that. For example I have asked @cgjgh
if he could make my web-push node PWA compliant (see here, since D2 has now become a PWA app. So turning it off (if possible) would have a lot of impact.

[colinl]

There must be a recognised solution to this problem, it is not specific to node-red to require re-authentication like this.

[cgjgh]

@colinl I use Authentik, a self-hosted auth provider with Google OAUTH as a social login option in front of NodeRed. In Edge on Windows I tried to replicate this issue by removing session cookies from Dashboard in an attempt to emulate session expiration. It did indeed act in the manner you described: blank screen on Dashboard (reloading dashboard didn't work), but navigating to NodeRed editor redirected to OAUTH login as it should. After logging in, Dashboard worked again.

Dev console in Edge showed the following error when Dashboard blank screen appeared:
Access to fetch at 'https://example_authentik_oauth_server.com' (redirected from 'https://example_nodered_instance.com/dashboard/_setup') from origin 'https://example_nodered_instance.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Wondering if your dev console shows the same when your session expires or if it's unrelated. Side note: I've set my session expiration in Authentik to 4 weeks which is probably why I never noticed this.

Edit: Edge was replicable, Chrome And Firefox were not.

[colinl]

I had not tried it on the PC (I normally access via the local network on the PC). I have now done so, using Edge, and when I get the blank screen I see in the developer tools
auth error: SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON

The CORS error makes some sense, but what this error means I have no idea.

In Brave it works ok, but I note that Brave does not have the Install App option.

[colinl]

@cgjgh would it be difficult to provide a setting in settings.js (for example) that disabled this feature, reverting to the previous Add to Home Screen option? Unless someone has a fix for the fundamental problem.

[cgjgh]

To be able to disable PWA dynamically after Vite build, from my tests all that would be necessary is to encase line 32 of main.mjs in a condition like so:

if (enablePWA) {
// register service worker
    registerSW({ immediate: true })
}

Also browser cache needs to be cleared and PWA removed.

Then you could make enablePWA configurable in D2 ui-base. Not quite sure how to at the moment. @joepavitt could you give some quick pointers on this? Reconnection notification config option could also be added.

[joepavitt]

Getting reports that this is also an issue with FlowFuse authentication too

[TotallyInformation]

Have people getting the CORS issue configured CORS for Node-RED? If not, the defaults would likely block you. That's what CORS does after all. It is by design.

Re the not JSON issue, that will be because some server is delivering HTML on the error.

[joepavitt]

Have people getting the CORS issue configured CORS for Node-RED? If not, the defaults would likely block you. That's what CORS does after all. It is by design.

Not sure, I've not had a chance to reproduce/investigate entirely, but white/blank pages at the point of authentication, and needing to revert back to FlowFuse platform in order to re-activate the Dashboard is the current report. Which aligns with what @colinl was seeing in the PWA behaviour with his OAuth

[colinl]

Have people getting the CORS issue configured CORS for Node-RED?

I cannot find how to do that. Can you elucidate please?

[arturv2000]

Hi

Just tries this yesterday and was having issues with login after added the app to home screen.

In my case, I have the Node-Red sites behind nginx, just add to add a couple of directives to the configuration

server {
  listen ***.***.com:**** ssl http2;
  server_name ***.***.com:****;

  # See https://ssl-config.mozilla.org/#server=nginx&version=1.18.0&config=intermediate&openssl=1.1.1k&hsts=false&ocsp=false&guideline=5.6see https://ssl-config.mozilla.org/#server=nginx&version=1.18.0&config=intermediate&openssl=1.1.1k&hsts=false&ocsp=false&guideline=5.6
  ssl_session_timeout 1d;
  ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
  ssl_session_tickets off;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
  ssl_prefer_server_ciphers off;

  ssl_certificate /etc/letsencrypt/live/***/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/***/privkey.pem;


  location / {
    # CORS Related, not sure if everything is necessary
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        #
        # Custom headers and headers various browsers *should* be OK with but aren't
        #
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
        #
        # Tell client that this pre-flight info is valid for 20 days
        #
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;
        return 204;
     }
     if ($request_method = 'POST') {
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' always;
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
     }
     if ($request_method = 'GET') {
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' always;
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
     }
    # End of CORS
    proxy_pass http://127.0.0.1:***;
    proxy_http_version 1.1;

    proxy_buffering off;
    proxy_request_buffering off;
    proxy_redirect off;

    proxy_set_header Host $http_host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_connect_timeout 3m;
    proxy_send_timeout 3m;
    proxy_read_timeout 3m;

    client_max_body_size 0; # Stream request body to backend
  }
}

It seems to have solved the issue, at least if using Basic Authentication it seems to be working now.

[cgjgh]

The above will only work with servers you're in control of though...

Here's a solution that seems to work with my auth setup: (@colinl wondering if you can try and replicate this)

In line 75 of main.mjs set dashboard setup fetch request to no-cors:

// GET our SocketIO Config from Node-RED & any other bits plugins have added to the _setup endpoint`
fetch('_setup', { mode: 'no-cors' })`

Then in the catch statement of the fetch request on line 176:

 console.log('auth error:', err)
 console.log('redirecting to:', window.location.origin + '/dashboard')
 window.location.replace(window.location.origin + '/dashboard')  

This will redirect to dashboard root on error which will then be redirected to auth.

My theory on why the blank screen error occurs is the setup request to NodeRed fails when unauthorized or session has expired. In PWA app this results in dashboard never loading while also not providing a way to fully reload (without cache) or navigate to NodeRed editor which would presumably fix the problem. Furthermore, reloading the page in the browser might not be effective either, as it only reloads the page from the cache. So, while the cached pages load successfully, it only reinitiates the setup request error.

To sum it up, PWA loads the webpage from cache, it (maybe) doesn't know that session has expired thereby effectively bypassing what would have resulted in a redirection to auth, so the cached pages succeed and only the setup request fails every time.

To be clear the above is only a proof of concept, ultimately you would probably make a CORS preflight request and catch the error there and redirect to auth before making the setup request which would remain CORS enabled.

[colinl]

@colinl wondering if you can try and replicate this

I will give it a go. Will have to wait for the situation to arise before knowing whether it sorts it, which may take a few days.

[arturv2000]

The changes made to the nginx conf, didn't work. The behaviour becomes even more erratic.

After adding the APP to the home screen, sometimes it stops working after one hours, other times after more than one day. And when it stops working in the shortcut in home screen even in the browser doesn't open. The surest way to recover is either to delete the browsing data, or to purposely entering a wrong URL (ex: /dash instead of /dashboard).

Now that i have updated more instances to V1.8.x or greater, is even happening on the PC browser (although very rarely) but in this case the workaround is simpler... CTRL + F5.

[colinl]

When you say it stops working, exactly what is the symptom that you see?

[colinl]

I am afraid the change doesn't work for me, at least on the laptop. The google auth has expired and now it is stuck in a loop continuously redirecting to /dashboard.

[arturv2000]

It starts doing on the PC browser the same as in android, when using the PWA App (Added to Home-screen) showing a blank screen.

In the network manager, the request for _setup was coming as "unauthorized"/"error".

In the meanwhile i have removed all the extra settings in the nginx.conf and it seems to have returned to normal.

For now, going to forget the PWA option, add to screen or install App (although only one or twice the popup to install app has shown in android) until this get fixed.

Did not attempt to perform the changes suggested by cgjgh, I am only mentioning the nginx.conf changes that I had suggested previously.

[colinl]

On Android, the google auth having expired, with the suggested mods, I just get the blank screen again. I don't know whether it is also permanently redirecting or not.

[joepavitt]

You're not alone in seeing that @arturv2000 - it does appear PWA stuff has completely broken any Dashboard 2.0 behind an authentication layer - it's very high up on my list of investigate this in more detail

[cgjgh]

I am unable to reproduce any blank screens with my setup which is behind Authentik auth provider as I mentioned. I’ve tested on iOS, Windows, and Android emulator, necessitating logins by simulating auth token expiration by either editing or removing cookies, the only methods I have now in a short time frame.

I should mention however that my D2 build is using an updated version of Vite-PWA and Vue as is currently being used in Vite-PWA project scaffolding and also a different service worker generation strategy. I didn't want to make another PR with these changes as PWA future with D2 seemed uncertain.

If anyone would like to test the exact version I'm using here it is: https://github.com/cgjgh/node-red-dashboard/tree/PWA-Update

The only changes from 1.9.0 as of now is last commit called PWA Update so you can manually make these changes if you prefer.

If you do plan on testing, please clear your cache and remove any previous D2 PWA apps before reinstalling.

[arturv2000]

@cgjgh Just tried to replace the dashboard by the version you have, and continue to have the same problem.

With my setup (using Windows with Edge or Chrome for browser) and the Node-Red in a Linux server using nginx as reverse proxy.

The way I am at the moment to reproduce this is:

• Let's assume we are accessing the dashboard normally
• Close all the browser windows (in case of google chrome also close/exit from the chrome icon in the system tray)
• Open again the browser
• Access the dashboard, it will stay a blank page until I force a refresh Shift + F5 or Ctrl + F5. In android is necessary to clear the "Cookies and site Data"

If I don't exit the browser (complete exit, close all instances of the process), it seems to kept working for a long time (at least up to 8 hours).

[arturv2000]

Just a small update

With this new version, and adding indication in nginx to disable cache

# kill cache
add_header Last-Modified $date_gmt;
add_header Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
if_modified_since off;
expires off;
etag off;

And opening the page and going to developer tools and force disable cache and making a few Ctrl+F5, then untick the disable cache. On PC (Windows - Edge and Chrome) seems to be working, when stating a browser session from a new browser process it always request the login and it load the page. Sometimes even appear a small popup windows indicating a new version available with the option to reload. Have seen this in other websites, seems to be a way to handle browser cache.

On Android, it is more tricky, it enters in a "loading loop" as Colin described before. The login popup shows again if we put a wrong address, like dashb, and after that going to dashboard. But if close the window (and remove chrome from the android background apps), it happens again when reopening the browser and entering the URL. Even if I clear the browser cache after successful login, after closing / removing from background it happens again.

[cgjgh]

@arturv2000 New version pop up is a feature of the PWA, prompt to update. I enabled it to allow for better transparency when new versions available instead of automatically updating. It should only appear on every new Vite build.

Another pop up you should be getting after a couple seconds is App is offline ready which signifies that service worker has completed precaching of files.

Can you navigate to the line where error occurs in the image?

Also, can you tell me the steps I can take to recreate your setup in Docker for example?

[arturv2000]

@cgjgh Will try during the weekend. Just tried redo the process (installing your version) in another server i have (test server, local network) and i am not being able to reproduce the issue.

But the server is setup differently, since it is in local network for tests is not being served by nginx and does not have https. In this condition it seems to be working "normally" either via Windows Edge Browser or android chrome browser. Since it doesn't have SSL is just a simple page, not a PWA app).

Today I am unable to make changes on the server (With https) I was trying this morning (demo ongoing for other stuff in the afternoon and I don't want to touch it).

[arturv2000]

@cgjgh Ok, demo took way less time than anticipated.

Was able to "touch" the server. I started by deleting the node_module folder inside node-red user folder, and also deleted node_modules where I had cloned you git repo. Also restored the nginx conf to the default one required for Node-Red site.

After installing everything and building the app, and uninstall original dashboard and install the new compiled one, on Windows (Browser Edge) is not showing any problems, it loads correctly the page and if I exit the browser and try to open again it works (after reopening the browser it requests again the authentication.

Regarding android, it enters the white page and loading loop.

In the meanwhile, via stackoverflow i think i found the solution for android.

But it seems to only work if i make npm run build:dev.

In the file main.msj in the `catch('err)' where was this line:

window.location.replace(window.location.origin + '/dashboard')

replaced by:

 window.location.href = window.location.origin + window.location.pathname + window.location.search + (window.location.search ? '&' : '?') + 'reloadTime=' + Date.now().toString() + window.location.hash;

And now in android (chrome browser) is working, if build:dev. if build normal, it returns to the white page and loading, and the url after a while is something likehttps://xxxxxxx.com:1111/dashboard/?&reloatTime=121212121212&reloadTime=121212121212......

And also find out why the install app wasn't showing. I am modifying the icons and site.webmanifest for my own icons, and the site.webmanifest didn't have the name, short_name and start_url defined.

UPDATE

This seems to work in android also

window.location.replace(window.location.origin + '/dashboard' + '?' + 'reloadTime=' + Date.now().toString() + Math.random());

[cgjgh]

@arturv2000 What happens if you make an endpoint in nodered with http in node and make the response a 302 redirect to your dashboard? Reaching endpoint would also first need to be authenticated after which redirect to dashboard should be good to go.

Example:

[{"id":"b4c8d8f441022d6d","type":"http in","z":"3d14fb98ea740a0b","name":"Auth Endpoint","url":"/auth","method":"get","upload":false,"swaggerDoc":"","x":310,"y":760,"wires":[["e80bf2a236fbfcf1"]]},{"id":"e80bf2a236fbfcf1","type":"http response","z":"3d14fb98ea740a0b","name":"Redirect to /dashboard","statusCode":"302","headers":{"Location":"http://localhost:1880/dashboard"},"x":550,"y":760,"wires":[]}]

• Change location in response node to dashboard url.

• Then in the catch block set the window.location.replace URL to http in endpoint.

Wondering if that would allow you to use build instead of build:dev

[arturv2000]

@cgjgh Damn, I hate when this happens in posts and emails... When I am almost finishing it someone disturbs me and when I look again to the PC assume that is completed.

Regarding the last UPDATE, the last code example works in Android (chrome) and with build in RELEASE mode.

Apparently that forces the browser to receive a query parameter, and if the parameter is not know/cache forces the browser to make a request that should answer with error by the server that redirects to the original page.

[cgjgh]

@arturv2000 My apologies for the oversight and thank you for your continued work on the issue.🙂

So, if I were to provide a brief summary, would I be correct in saying that the code from the branch PWA Update works as is on PC Windows, but on Android still requires the anti-caching URL:

window.location.replace(window.location.origin + '/dashboard' + '?' + 'reloadTime=' + Date.now().toString() + Math.random());

Can I update the branch then to include this fix and/or submit a PR to address the blank screen issue?
Asking because not being able to reproduce issue so can not mark as fixed.

[arturv2000]

In my current use case, yes it seems to be working.

The use case is:

• Node-Red Dashboard using the cgjgh PWA-Update branch with the modification indicated bellow
• Node-Red is being served by nginx as reverse proxy, nginx supposedly with default configuration required for Node-Red (I think I copied from the forum somewhere)
• SSL enabled

NOTE: As indicated before, if trying to use this branch is recommended to clear browser cache for the test domain before attempting. Not sure if necessary since initially wasn't really working.

Have the PWA app installed on android phone (Android 13) and tablet (Android 14) since yesterday evening and they are still opening without issues. The same for Edge and Chrome browser on Windows, and on Linux (raspberryPi) Firefox and Chromium.

Not sure about IOS no way of testing at the moment.

The changes I made to your code where the following:

    .catch((err) => {
        console.log('auth error:', err)
        console.log('redirecting to:', window.location.origin + '/dashboard')
        //window.location.replace(window.location.origin + '/dashboard') //Original, seems to have no issues with Edge and Chrome on Windows, doesn't work on Android (Not tested on Linux browser)
        //window.location.href = window.location.origin + window.location.pathname + window.location.search + (window.location.search ? '&' : '?') + 'reloadTime=' + Date.now().toString() + window.location.hash; // Also works on Edge + Chrome on windows, doesn't work on android

        window.location.replace(window.location.origin + '/dashboard' + '?' + 'reloadTime=' + Date.now().toString() + Math.random()); //Seems to work on Edge and Chrome on Windows Chromium and Firefox on Linux, and also on Chrome Android (an also as PWA App)
    })

Only changed the .catch((err) handler and replaced the redirect.

Never tried even on Windows without any redirect.

[cgjgh]

@arturv2000 Ok, I’ll update the branch with your changes. Thank you again for the work you’ve done.

[arturv2000]

I have installed this version of node-red-dashboard in two more instances (have three total with this version) and they all seem to be working correctly either in PC or Android.

One question regarding the PWA's.

I have several instances of Node-Red running in the same server, each one is a specific TCP Port (1880, 1881, 1882, etc...).

Is It possible to install one PWA for each instance in the smartphone?

At the moment it seems that is not possible, since if I install the PWA for instance in port 1880 when accessing site on port 1881 it doesn't give the option to install the PWA, only to open the previous installed PWA.

For what I could understand in order to do this there have two options, one register the service worker differently for each app (scope), or using different subdomains for each app (sub1.mysite.com:1881/dashboard and sub2.mysite.com:1882/dashboard)

Is my understanding correct?

Thank You