Repeated prompts for password #165
Comments
|
@scargill can you, for the record, describe how you've secured your dashboard - just so we don't start debugging the wrong thing. |
|
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) |
|
@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... Then I have security for node-red and node-red/ui just after functionGlobalContext... // https: { 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 |
|
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 <#165 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/ABzUg1Y66Vn-CE-IktK7U3qNvTJK1LUwks5rcxcygaJpZM4MBwhJ> .
|
|
I have noticed the same behavior and have mentioned it a few times previously in newsgroup/slack. 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! |
|
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. |
|
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. |
|
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. |
|
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.
|
|
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. |
|
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... Apart from that I'm not sure what it is that causes the browser to decide to re-ask for the password. |
|
@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 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. |
|
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. |
|
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:
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:
This is an example of the flow I have that includes the template node that includes the fontawesome a-lightbulb-o markup:
|
|
I think this is related to this upstream 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 - c566a97 |
|
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. |
|
hello people... i'm just new here. did you find a solution for that? |
|
sorry - not tried ios11 yet - not about to upgrade my phone until they have fixed several bugs. |
|
actually it looks like a system problem to store basic http auth, more than a node-red problem |
|
I don't know about anyone else but this issue is fixed for me and has been fixed since the c566a97 commit. |
|
well in my iphone with IOS 11 it doesnt save the credentials anymore |
|
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 ***@***.*** > 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
<#165 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/APgUS2Ade8hL7e5_Jox03Psm-gJS3XZKks5slr94gaJpZM4MBwhJ>
.
|
|
fwiw I'm an android 6.0.1 user. This issue appears to have morphed into an IOS specific issue. |
|
well... anything you can suggest? |
|
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. |
|
:) @jjssoftware hope so @dceejay help us |
|
@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. |
|
@knolleary i perfectly understand and respect that |
|
Too late for me now...
…On Mon, 25 Sep 2017 at 14:36, Dave Conway-Jones ***@***.***> 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
<#165 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/APgUSzwb8HYLwvFItGVtFsiDcAILi2s5ks5sl54-gaJpZM4MBwhJ>
.
|
|
I'm sure IOS11.1 will be along shortly |
|
@dceejay - "I think this is related to this upstream 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 |
|
The Fixfa post install script already removes the ? From the urls so that should not be the problem |
|
In that case, it's still very much a problem here, and not really sure how to troubleshoot... |
|
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: ..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. |
|
@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. |
|
I'm pretty convinced now that this is a weather-icons issue rather than node-red, so I've created an issue there - Paul-Reed/weather-icons#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 c566a97 - but its not easy as large chunks of code have changed in the diffs. Paul |
|
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 c566a97 (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. |
|
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). |
|
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. Paul |
|
@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; Any thoughts how this can be managed without adding the static folder files to the appcache? Paul |
|
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. |
|
Any thoughts how that could be implemented ? |
|
I feel a bit of to-ing and fro-ing is about to start so I'll pick this up with you in slack |
|
Here is fine seeing as we are here |
|
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/ |
|
Has any decision been made about the discussion that we had last Sunday regarding appcache please. |
|
Yes possibly - not had time to think about it, let alone try any code... |
|
HEY Guys |
|
no |
|
Since the weather-icons CSS & font files have been integrated into the dashboard and cached, I haven't had any further requests for auth, so seems sorted for me. However, I suspect that this may persist for other users who are loading modules, fonts, css etc from a shared folder, and are not included in the cache. The answer for those users may be to manually add them to their app.cache, but of course those changes would be overwritten every time the dashboard is updated, which is not ideal.... |
|
Closing this due to silence - we think the basic case is now fixed, and have workarounds for others. |
|
it is not fixed at all |
|
A few more details would be helpful.... |
|
same problem here... on the iphone i can't save my credentials when opening my node-red page (ui)... so everytime i need to write down user/pass to control my house |
|
I know this is an old thread but I have 2 Android phones both with repeated but different UID/Password issues. Been running Node-Red for over a year on a Raspberry Pi, using Peter Scargill's script, to drive my Sonoffs. Works perfectly except for the dashboard on my Android phones. The dashboard via my laptop {Win 10} works fine.. Phone #1: Android: About 50% of the time I get the dialog box for the uid/password and if I enter the proper data it will NEVER log me in. If however I just hit "Cancel" it logs me in and the dashboard works fine. Phone #2: Android: {same carrier Republic Wireless} The uid/password dialog box ALWAYS opens and is already filled in but it requires hitting the "Sign In" button 5 times {very repeatable always 5} then it will log me in. Note: Hitting the "Cancel" button like for Phone #1 does not work. My Node-Red project does NOT connect to the internet. Just local control. |
|
This is a really long thread, but I have the same problem. On Android clearing data and logging in to chrome once again solves the problem for a while, but not forever. Maybe it is enough to just clear cookies, or something, I don't know... |
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.
The text was updated successfully, but these errors were encountered: