Repeated prompts for password

[scargill]

I raised this ages ago - heard nothing - then someone else had the same problem - and now another today - so here's an issue.

The login - I have separate logins for Node-Red and Node-Red UI. The latter asks for username and password - especially on mobiles, WAY too often - more than anything else I've come across in web pages or apps... detracting somewhat from easy use of the dashboard (I use mine to control lights etc. Can anyone look at this and see if there is something wrong or a better way.

I changed phone makes a while ago and it made no difference.

[knolleary]

@scargill can you, for the record, describe how you've secured your dashboard - just so we don't start debugging the wrong thing.

[ghost]

Wanted to report same thing, it changes a version or two ago. On dashboard, on iOS, I connect to dashboard with uid, pwd, through a dynamic DNS service (got a d-link router, using dlinkddns), to the RPi, sitting in DMZ. But exact same problem when on home network with phone. I open the app in Safari, then store the link on the "Add to Home Screen". Then it has an icon like an app. The first time you click on that, it asks for uid / pwd again, but there after, if you click on the home screenicon, it does not ask for the uid/pwd again.

But.....

After you have opened the html5 dashboard screen, and say go to home screen, or open another app, if you go back to the html5 screen, it wants the uid/pwd again. If you then kill it (swipe-up after home button double-click), and launch it again from home screen, it does not ask for the uid/pwd again. This is very annoying, and almast makes it unusable. Does not have this bahaviour on computer browser .... (Apple Mac - Safari)

[scargill]

@knolleary Hi there.

My security is old, but it was on the Node-Red website... hang on...

So in /home/pi/.node-red there is settings.js and I've a few things in there.. here they are....

Firstly I set a directory for my stuff...

httpStatic: '/home/pi/.node-red/public',

Then I have security for node-red and node-red/ui just after functionGlobalContext...

    adminAuth: {
    type: "credentials",
    users: [{
       username: "admin",
        password: "$2a$08$sQ6R4vPSqvX0nthS7y2fQOHIey0game0OVvjwkuwQxxxxxxxxxxxx",
        permissions: "*"
    }]
},

// https: { // key: fs.readFileSync('/home/pi/SelfSigned-Cert-Creator/server/privkey.pem'), // cert: fs.readFileSync('/home/pi/SelfSigned-Cert-Creator/server/fullchain.pem') // },

  httpNodeAuth: {user:"user", pass:"$2a$08$fInbgDanmhpr.IGeeUE5..GVAhd.BpwfU5XaY8v6sxxxxxxxxxxxx"}, 

As this is open - in each case I've replaced the last 12 characters with x. But the lengths etc are as I have.

I copy this lot into new installations....

And that's it - my installation is also on HTTPS: but that's relatively new and had no effect on passwords...

Need any more info or testing anything - just shout

[scargill]

Sounds about right – better than my description. Seems to be worse on mobile than on PC.

From: jroux1 [mailto:notifications@github.com] Sent: 15 February 2017 16:18 To: node-red/node-red-dashboard node-red-dashboard@noreply.github.com Cc: Peter Scargill pete@scargill.org; Mention mention@noreply.github.com Subject: Re: [node-red/node-red-dashboard] Repeated prompts for password (#165)

Wanted to report same thing, it changes an version or two ago. On dashboard, on iOS, I connect to dashboard with uid, pwd, through a dynamic DNS service (got a d-link router, using dlinkddns), to the RPi, sitting in DMZ. But exact same problem when on home network with phone. I open the app in Safari, then store the link on the "Add to Home Screen". Then it has an icon like an app. The first time you click on that, it asks for uid / pwd again, but there after, if you click on the home screenicon, it does not ask for the uid/pwd again.

But.....

After you have opened the html5 dashboard screen, and say go to home screen, or open another app, if you go back to the html5 screen, it wants the uid/pwd again. If you then kill it (swipe-up after home button double-click), and launch it again from home screen, it does not ask for the uid/pwd again. This is very annoying, and almast makes it unusable. Does not have this bahaviour on computer browser .... (Apple Mac - Safari)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/node-red/node-red-dashboard/issues/165#issuecomment-280038686 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUg1Y66Vn-CE-IktK7U3qNvTJK1LUwks5rcxcygaJpZM4MBwhJ .

[Paul-Reed]

I have noticed the same behavior and have mentioned it a few times previously in newsgroup/slack. My httpNodeAuth is set up the same as Pete's above.

When I first secured the ui, I used a long secure password, but it's gradually got shorter and simpler because of the number of times that I have to type it in!

[Paul-Reed]

Been keeping an eye on windspeed today (storm Doris), and so far have had to enter my credentials into my dashboard 8 times via my phone. This can't be right!

[knolleary]

Please, no more 'me too' comments unless there's something that will contribute to understanding what is going on here and help us resolve it.

[bebo-dot-dev]

Here's an observation that I hope might help. I was taking a look at my dashboard on my laptop in chromium - there was no sign of any prompt for a username/password in the first instance and it generally seems to be ok on desktop for me. I do occasionally see a prompt for a username/password on android mobile in chrome.

I then noticed in chromium that there was some sort of issue with the dashboard.appcache manifest being served (a 401 error):

So next up I navigated to chrome://appcache-internals in a new chromium tab, deleted the manifest entry that was present there for the dashboard. I then switched back to my dashboard tab and performed an "Empty Cache and Hard Reload" refresh in the page and I immediately saw a prompt for a username/password:

After entering my username/password, the dashboard.appcache manifest 401 problem was gone and again no more requests for username/password.

Then since manually fixing the manifest 401 problem by removing the entry, I've removed the entry again, refreshed the dashboard and not been prompted for username/password. So it does seem a bit odd that the manifest is somehow "in the frame" and under some circumstances is having an effect on credentials being requested.

So it's a bit of a stretch but..perhaps something similar is happening on mobile (which is more difficult to see due to lack of dev tools) where the dashboard.appcache manifest is being lost / corrupted / binned off, which in turn is causing a username/password prompt.

[ghost]

Yup, tried this on iOS iPhone, deleted home screen icon, cleared cache on Safari, opened page on Safari, credentials, stored icon on home screen, open homescreen icon, uid and pwd, there after okay. Do far, so good!

Update: nope, spoke too soon. It works if you wait a short while after putting app in the background, but if you wait say 15min, still old bahaviour.

[bebo-dot-dev]

I really didn't mean to suggest that a browser cache clear is the magic fix for what's going on here. If that's what you got from my last comment, I didn't intend for that at all. I meant to suggest that the dashboard.appcache manifest could be getting lost / is failing or could somehow be connected to prompts for username/password on mobile.

That said, I admit that this is a leap of faith of a suggestion and at the moment I've got nothing other than what I recorded in the screenshots and the process that I followed to remove the manifest and refresh the dashboard to force the username/password prompt to appear as evidence of this connection.

[dceejay]

just something to try.... can you try editing the dist/dashboard.appcache file and remove the index.html line ? Then flush browser cache, reload etc etc... Not sure why that would help but have seen some reports that caching the index may be a bad thing (or rather, caching the file that references the manifest)

Apart from that I'm not sure what it is that causes the browser to decide to re-ask for the password.

[bebo-dot-dev]

@dceejay ok I've made the change. I'll report back with anything I see.

Edit: I see that the manifest 401 error is back in the chromium console window:

- Application Cache Error event: Manifest fetch failed (401)

I don't know why this happens but it doesn't seem to harm render performance when it crops up. So far the only way I've found to get rid of this 401 condition is to navigate to chrome://appcache-internals/ and then manually delete the manifest item..after which I'm prompted to input username/password.

Edit: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401. "The HTTP 401 Unauthorized client error status response code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource."

So it would appear that this manifest 401 error is symptomatic of basic authentication failure / needing credentials to be supplied and yet when it's there in the console window, I'm not prompted to input username/password until I manually remove the manifest item.

[ghost]

I upg dash to 2.3.5 last night, after clearing cache in iOS Safari, iPhone, have not had the uid/pwd prompt since.... will report back if it comes back.

[bebo-dot-dev]

This is a follow up to the recent discussion on slack where I mentioned that inclusion of the following markup within a dashboard template node results in the username/password prompt appearing:

<i class="fa fa-lightbulb-o fa-2x" aria-hidden="true"></i>

The inclusion of this markup results in a http request for the fontawesome-webfont from /ui/fonts/fontawesome-webfont.woff2?v=4.7.0 and the username/password prompt is directly related to the browser http request for this fontawesome-webfont.

The http request for the font is made as a result of the way the fontawesome font is referenced in app.min.css around line#33:

@font-face{font-family:FontAwesome;src:url(../fonts/fontawesome-webfont.eot?v=4.7.0);src:url(../fonts/fontawesome-webfont.eot?#iefix&v=4.7.0) format('embedded-opentype'),url(../fonts/fontawesome-webfont.woff2?v=4.7.0) format('woff2'),url(../fonts/fontawesome-webfont.woff?v=4.7.0) format('woff'),url(../fonts/fontawesome-webfont.ttf?v=4.7.0) format('truetype'),url(../fonts/fontawesome-webfont.svg?v=4.7.0#fontawesomeregular) format('svg');

This is an example of the flow I have that includes the template node that includes the fontawesome a-lightbulb-o markup:

[{"id":"67286af8.d94d54","type":"tab","label":"Lights"},{"id":"bb1b6398.36e5c","type":"mqtt out","z":"67286af8.d94d54","name":"","topic":"/Sonoff1/gpio/12","qos":"0","retain":"","broker":"3c3b3d51.371832","x":920,"y":100,"wires":[]},{"id":"3d297a24.04dcf6","type":"ui_switch","z":"67286af8.d94d54","name":"switch","label":"1st Floor Landing","group":"87489c5.879f86","order":0,"width":"5","height":"1","passthru":true,"topic":"","style":"","onvalue":"1","onvalueType":"str","onicon":"","oncolor":"","offvalue":"0","offvalueType":"str","officon":"","offcolor":"","x":650,"y":100,"wires":[["8b48a0a7.e180b","2c97640a.bfa3cc"]]},{"id":"b6d8bbc7.8c2dc8","type":"mqtt in","z":"67286af8.d94d54","name":"","topic":"/Sonoff1/gpio/11","qos":"0","broker":"3c3b3d51.371832","x":120,"y":100,"wires":[["55e96104.e20e3"]]},{"id":"55e96104.e20e3","type":"switch","z":"67286af8.d94d54","name":"check input msg","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"1","vt":"str"}],"checkall":"true","outputs":1,"x":340,"y":100,"wires":[["b757eb0c.68f858"]]},{"id":"8b48a0a7.e180b","type":"function","z":"67286af8.d94d54","name":"store","func":"global.set(\"Sonoff1\",msg.payload);\nreturn msg;","outputs":1,"noerr":0,"x":770,"y":100,"wires":[["bb1b6398.36e5c"]]},{"id":"b757eb0c.68f858","type":"function","z":"67286af8.d94d54","name":"flip state","func":"if (global.get(\"Sonoff1\")===\"1\") {\n msg.payload=\"0\";\n} else {\n msg.payload=\"1\";\n}\nreturn msg;","outputs":1,"noerr":0,"x":500,"y":100,"wires":[["3d297a24.04dcf6"]]},{"id":"94e8f860.032918","type":"inject","z":"67286af8.d94d54","name":"","topic":"","payload":"1","payloadType":"str","repeat":"","crontab":"","once":false,"x":510,"y":160,"wires":[["3d297a24.04dcf6"]]},{"id":"bf205ff3.1e23","type":"inject","z":"67286af8.d94d54","name":"","topic":"","payload":"0","payloadType":"str","repeat":"","crontab":"","once":false,"x":510,"y":200,"wires":[["3d297a24.04dcf6"]]},{"id":"2c97640a.bfa3cc","type":"ui_template","z":"67286af8.d94d54","group":"87489c5.879f86","name":"","order":0,"width":"1","height":"1","format":"<i class=\"fa fa-lightbulb-o fa-2x\" aria-hidden=\"true\" ng-style=\"{color: (msg.payload || '0') === '0' ? '#F0F0F0' : '#FFFF00', opacity: (msg.payload || '0') === '0' ? '0.2' : '1'}\"></i>","storeOutMessages":true,"fwdInMessages":true,"x":780,"y":160,"wires":[[]]},{"id":"3c3b3d51.371832","type":"mqtt-broker","z":"","broker":"192.168.0.2","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"willTopic":"","willQos":"0","willPayload":"","birthTopic":"","birthQos":"0","birthPayload":""},{"id":"87489c5.879f86","type":"ui_group","z":"","name":"Sonoff Wifi Switching","tab":"f6e4116e.4ec4","order":7,"disp":false,"width":"6"},{"id":"f6e4116e.4ec4","type":"ui_tab","z":"","name":"Lighting","icon":"lightbulb_outline","order":5}]

[dceejay]

I think this is related to this upstream

https://github.com/FortAwesome/Font-Awesome/issues/3286

so not sure how we can fix it just yet - apart from say - in the meantime don't use font awesome fonts.

manually patched fa css files incorporated into dist - c566a97a1d9adaa35d94a9592a67b173e21d5859

[aidanruff]

I have had the problem of logging into my ui. I looked into settings.js and found that 'httpNodeAuth' had defaulted to a username of 'user' instead of 'admin', whilst thae main node-red editing login was still 'admin' - logical, I guess, in that you might want others to see the dashboard, but not to be able to edit. The password was set to be the same by default, but is easy enough to change.

[claudiofrancesconi]

hello people... i'm just new here. well i have node-red on raspi 3 and i use it for a domotic system specially to open my gate and front door... so i use it quite often. No problems until yesterday, when i updated my iphone to new ios 11... after that i can't store my user/password anymore... and everytime i open the node-red ui page from the home screen bookmark it keeps asking me for credentials everytime... On the other hand if i open it through safari the password is recognized automatically and no problems...

did you find a solution for that? i tried everything... even to bookmark an address like http://user:pass@xx.xx.xx.xx but it won't let me save it

[dceejay]

sorry - not tried ios11 yet - not about to upgrade my phone until they have fixed several bugs.

[claudiofrancesconi]

actually it looks like a system problem to store basic http auth, more than a node-red problem

[bebo-dot-dev]

I don't know about anyone else but this issue is fixed for me and has been fixed since the https://github.com/node-red/node-red-dashboard/commit/c566a97a1d9adaa35d94a9592a67b173e21d5859 commit.

[claudiofrancesconi]

well in my iphone with IOS 11 it doesnt save the credentials anymore

[ghost]

Same with me, and even if I try add the credentials in iOS under

Accounts & Passwords Apps & Website Passwords

It does not help. This is annoying, and makes the phone 'apps' unusable.

I even deleted it from the home screen, re-added, not working.

Also upgraded to UI 2.5.0.

Any solution somewhere for this?

On 24 September 2017 at 22:45, Claudio Francesconi <notifications@github.com

wrote:

well in my iphone with IOS 11 it doesnt save the credentials anymore

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/node-red/node-red-dashboard/issues/165#issuecomment-331739062, or mute the thread https://github.com/notifications/unsubscribe-auth/APgUS2Ade8hL7e5_Jox03Psm-gJS3XZKks5slr94gaJpZM4MBwhJ .

[bebo-dot-dev]

fwiw I'm an android 6.0.1 user. This issue appears to have morphed into an IOS specific issue.

[claudiofrancesconi]

well... anything you can suggest?

[bebo-dot-dev]

I'm sorry afraid not, as I said I'm an android user and it appears to be working fine here. The good news is that it looks like @dceejay is an IOS user and imo he's your best hope for a fix.

[claudiofrancesconi]

:) @jjssoftware hope so @dceejay help us

[knolleary]

@claudiofrancesconi to be clear, this appears to be a change in how iOS stores credentials. I'm not sure what you expect Node-RED to do about that. We have nothing to suggest.

Long term, we need a better login mechanism for the dashboard that doesn't rely on browser-based basic authentication. But we have no developer resource available to look at that currently.

[claudiofrancesconi]

@knolleary i perfectly understand and respect that

[dceejay]

yes - sorry - not about to take on debugging ios11. Happy to pass on the advice not to upgrade :-)

[ghost]

Too late for me now...

On Mon, 25 Sep 2017 at 14:36, Dave Conway-Jones notifications@github.com wrote:

yes - sorry - not about to take on debugging ios11. Happy to pass on the advice not to upgrade :-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/node-red/node-red-dashboard/issues/165#issuecomment-331867407, or mute the thread https://github.com/notifications/unsubscribe-auth/APgUSzwb8HYLwvFItGVtFsiDcAILi2s5ks5sl54-gaJpZM4MBwhJ .

[dceejay]

I'm sure IOS11.1 will be along shortly

[Paul-Reed]

@dceejay - "I think this is related to this upstream FortAwesome/Font-Awesome#3286 so not sure how we can fix it just yet - apart from say - in the meantime don't use font awesome fonts."

Any way to bring this to some sort of conclusion, as it doesn't look as though this issue is ever going to get fixed upstream, it's been an open issue (amongst over 4,000 others!) for three and a half years now, and is still causing problems for us NR users.

I appreciate that this is not directly a node-red problem, but NR refers to FA throughout it's documentation, and when users follow those guides we hit a brick wall, and cannot protect the endpoints. If I enable httpNodeAuth, I would have to re-auth my android phone 3 or 4 times a day, which is clearly not practical.

I've read the FA issue posts, and don't really understand what exactly is causing the problem, but if it can't readily be fixed locally here, should NR disassociate from FA, and concentrate on alternative icon sets such as material design?

Paul

[dceejay]

The Fixfa post install script already removes the ? From the urls so that should not be the problem

[Paul-Reed]

In that case, it's still very much a problem here, and not really sure how to troubleshoot... The only thing I can think of, that is different to most users, is I'm loading & using weather-icons, any possibility that a similar fix is needed regarding add-ins? (grasping at straws!!) It's hard to see what changes you made in https://github.com/node-red/node-red-dashboard/commit/c566a97a1d9adaa35d94a9592a67b173e21d5859

[bebo-dot-dev]

I do use font-awesome fonts here, have done for a long time and as previously mentioned I no longer have this issue. Here's the content from one of my flow templates:

<i class="fa fa-lightbulb-o fa-2x" aria-hidden="true" ng-style="{color: (msg.payload || 'OFF') === 'OFF' ? '#F0F0F0' : '#FFFF00', opacity: (msg.payload || 'OFF') === 'OFF' ? '0.1' : '1'}"></i>

..definitely font-awesome and node-red / dashboard is working here with no unexpected or annoying username/password prompts. The only time that I'm prompted to reinput my username/password nowadays is if I manually flush the appcache in the browser or if I restart node-red on the server.

[bebo-dot-dev]

@Paul-Reed have you tried manually adding the path to your weather-icons into the /node_modules/node-red-dashboard/dist/dashboard.appcache ? If not I suggest you try making this change, restart node-red, fully flush the browser appcache for the dashboard (for chrome / chromium you can delete the item in chrome://appcache-internals) and then test for a while. I know this suggestion isn't a permanent solution and is a bit hacky but it would be interesting to know if this change has a positive effect.

[Paul-Reed]

I'm pretty convinced now that this is a weather-icons issue rather than node-red, so I've created an issue there - https://github.com/Paul-Reed/weather-icons/issues/3 to avoid polluting issues here.

Any help would be appreciated.

Thanks @jjssoftware I'll give that a try. I'm also going to locate what changes @dceejay made in https://github.com/node-red/node-red-dashboard/commit/c566a97a1d9adaa35d94a9592a67b173e21d5859 - but its not easy as large chunks of code have changed in the diffs.

Paul

[bebo-dot-dev]

I believe it was removal of the query string version v=4.7.0 parameter from the font-awesome fonts within dist/css/app.min.css that fixed this issue for me. This is what @dceejay refers to when he mentions "The Fixfa post install script": https://github.com/node-red/node-red-dashboard/blob/master/fixfa.js - it's a css file modifier included in the gulp build pipeline that strips the versioning stuff out of font-awesome.css before it gets built into the final app.min.css

I think if anyone solely suffered from this issue due to use of font-awesome fonts prior to https://github.com/node-red/node-red-dashboard/commit/c566a97a1d9adaa35d94a9592a67b173e21d5859 (like me), the issue is now fixed for these users. Clearly there are other reasons to trigger this condition though and it does live on for some users.

[dceejay]

Looking at the weather-icons I don't think they have the same issue. But it may well be worth trying to add your icons (and maybe any other relevant js libs you use) to the same cache - just add the relative file paths to the dist/dashboard.appcache file (noting that it will get overwritten if/when you update dashboard - but certainly ok for a test).

[Paul-Reed]

Thanks both, it would be good to resolve this, because if it causes a problem in weather-icons, I assume it would cause a problem in similar sideloaded files too. The font files & associated css files are now added to the appcache, and so far so good, but I'll test over the next 24hrs and reply back.

Paul

[Paul-Reed]

@jjssoftware @dceejay - I can confirm that by adding the font & css files to the appcache, does stop the repeated auth requests, and it has run solidly since, so yes a positive effect - good call.

To see if this issue was confined to weather-icons, I also tested another sideloaded project - Nest Thermostat, which also has it's supporting css & js files held within a NR static folder, and which also triggered similar repeated auth requests; GET https://digitalnut.co.uk:8443/thermostat/thermocss/thermo.min.css net::ERR_ABORTED

Any thoughts how this can be managed without adding the static folder files to the appcache?

Paul

[bebo-dot-dev]

hey @Paul-Reed that's really good news and confirms what I hoped would happen. To be completely honest I don't know enough about node-red to know why requests to external resources cause this behaviour but I had a feeling the appcache hack would work.

I've worked around a similar problem in the past where I was dependent on the external skycons.js resource in one of my flows but rather than adding this to the appcache, at that time I decided to minify and inline the JS directly into a dashboard template node because fiddling with the appcache did feel like a temporary hack of a fix, it only lasts until the next dashboard update comes along and then it needs to be reapplied.

Inlining external resources into template nodes is a potential workaround but that can get clunky and very messy fast if you have many js, css, fonts i.e. fonts, images need to be converted into data-uris for insertion into css etc

I know that it's frowned upon to discuss potential platform features around here without having mentioned them in slack / elsewhere first but given this issue has been knocking around for so long I'm going to stick my neck out and make this suggestion here and now: can we please have a dashboard feature that enables custom resource paths to be selected / picked and inserted into the appcache as required - enabling a dynamically built appcache :)

Not sure if that's going to fly - this could be considered an edge case issue.

[dceejay]

Any thoughts how that could be implemented ?

[bebo-dot-dev]

I feel a bit of to-ing and fro-ing is about to start so I'll pick this up with you in slack

[dceejay]

Here is fine seeing as we are here

[bebo-dot-dev]

for the record, the discussion about a potential new feature to enable a dynamically built appcache was continued here: https://node-red.slack.com/messages/C1DH77X1V/

[Paul-Reed]

Has any decision been made about the discussion that we had last Sunday regarding appcache please. If we have to keep editing the appcache, I'll update my repo to reflect that. However, it would be a shame, because so far, all personalisations & enhancements are neatly wrapped up within the user directory, making NR easy to quickly fully restore in the event of a problem.

[dceejay]

Yes possibly - not had time to think about it, let alone try any code...

[claudiofrancesconi]

HEY Guys any news to store credentials on iphone new IOS for node-red UI interface?

[dceejay]

no