Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
A query for both you and Ralph: Do these techniques somehow prevent the same behaviour as was occurring with Chromium, where logins were being 'remembered' across sessions? I think you’ll see a similar effect - that the basic auth credentials will be ‘remembered’, but I don’t think that is related to any session information. Ie - if you have a login mechanism separate to Basic Auth, then having or not having Basic Auth won’t affect how the login mechanism works (ie the session - can be in a database, in a cookie, in a query string). So, it’s a no - they won’t prevent the same behaviour, as they aren’t related to the python login. -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Saturday, 30 January 2021 09:46:59 GMT Stephen Wolff wrote: > You can do it with nginx as well - and it’s as simple as with Apache: > > - > https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-> > basic-authentication/ > > But as you say, your system is pretty low-risk to hacking, so maybe no > point. Stephen, Thanks for that. It might come in useful one day. A query for both you and Ralph: Do these techniques somehow prevent the same behaviour as was occurring with Chromium, where logins were being 'remembered' across sessions? -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
Hi Terry, I'm going to use nginx rather than Apache, simply because it is what I used for the original Audio Guide and Quiz Webserver so I have prior experience with it. Also it is lightweight which is also a bonus with the RPi and one of the reasons that I chose it 3-4 years ago. You can do it with nginx as well - and it’s as simple as with Apache: - https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/ But as you say, your system is pretty low-risk to hacking, so maybe no point. Cheers, Stephen -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Saturday, 30 January 2021 08:30:22 GMT Ralph Corderoy wrote: > If you don't need to enforce that short 15-minute authorisation time > then I think Stephen is right that it's easier to configure Apache to > guard the control page, with your Python knowing nothing about it. > https://httpd.apache.org/docs/2.4/howto/auth.html Ralph, I'm going to use nginx rather than Apache, simply because it is what I used for the original Audio Guide and Quiz Webserver so I have prior experience with it. Also it is lightweight which is also a bonus with the RPi and one of the reasons that I chose it 3-4 years ago. After the lengthy discussions over this query, I'm fairly comfortable about the cause of the problem and believe that the risk of a device used by a member of staff or privileged volunteer falling into the hands of a bad actor who might exploit this is low enough to be vanishingly small. Bear in mind that this Webserver has no access from the Internet, other than via the VPN Server, so any attack will have to be attempted within range of the the site Wifi. I would think that a casual thief is probably going to head for his local fence or drug pusher rather than hanging around the WMT trying to hack into the system. Thanks for the suggestion though. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
Hi Terry, > > - Does the whole site require authentication? > > No. Only the Control Page. > > > - Are the users who need to authenticate a handful so they can be > > educated in responding to the browser's login prompt? > > Yes. A very slack handful. :-) Probably no more than half a dozen. > > > - Do the users share devices provided at the site? > > No they use their own. > > > - How long should a ‘login’ last? > > Probably only 10 to 15 Minutes. If you don't need to enforce that short 15-minute authorisation time then I think Stephen is right that it's easier to configure Apache to guard the control page, with your Python knowing nothing about it. https://httpd.apache.org/docs/2.4/howto/auth.html -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Tuesday, 26 January 2021 18:16:58 GMT Patrick Wigmore wrote: > Sorry for any confusion I may have injected. Any confusion is definitely created by me. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Tuesday, 26 January 2021 17:48:32 GMT Ralph Corderoy wrote: > Either way, cookies aren't part of the mechanism, even if they may be > present for other reasons which explains why clearing cookies didn't > have a matching effect. But it did > Rewinding some months... When were these questions asked? Certainly not months ago, because I only started writing this Web App a few weeks ago. Anyway: > - What's the website? It's on the WMT Network, which is an intranet. It provides for Control and Monitoring of the Minster Music and Bells System. This is a re-engineered piece of kit which used to be controlled with toggle switches. > - Does the whole site require authentication? No. Only the Control Page. > - Are the users who need to authenticate a handful so they can be > educated in responding to the browser's login prompt? Yes. A very slack handful. :-) Probably no more than half a dozen. > - Do the users share devices provided at the site? No they use their own. > - How long should a ‘login’ last? Probably only 10 to 15 Minutes. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Tue, 26 Jan 2021 14:42:22 +, Terry Coles wrote: > Oh. OK. I understand that is the code the Flask method and not the > code for the Flask Development Server, but surely it's the server > that sets the cookie? The term 'server' can become a bit muddled here. If you look at it from a browser or HTTP protocol point of view, then the web server and any frameworks that run in it or alongside it, and any code you write that runs in the framework, are taken together to comprise a server. That is how I meant the word "server" in my previous response to this thread, when I said as much as it was the server's prerogative to decide whether a session cookie corresponded to a valid session. If I look at it that way, then I can say "yes, the server sets the cookie". But that doesn't answer your question, because I think you are looking at it from a more server-internal point of view, where Flask, and the Flask code you write, is treated as being a separate thing and not as part of the 'server'. I would say that this is a valid way to use the word 'server'. Looking at it that way, then I would say that, yes, the server sets the cookie, but that is only half the story, because Flask and your code can be the reason why the server ends up setting a cookie. If you were having Flask manage sessions for you, then it would be Flask telling the server to set a cookie. But Ralph is right; the code for flask-httpauth doesn't appear to use sessions or cookies in its implementation of HTTPBasicAuth. So, the fact that clearing browsing data seemed to clear the active log-in has probably been a bit of a red herring, and I have been guilty of being insufficiently curious. I am now given to assume that Chromium is caching the authentication credentials in a manner that survives browser restarts, or perhaps Chromium is not really being fully shut down when you close the browser, and that is why the authentication persists. Maybe when you cleared the browsing data, it was not the clearing of the cookies but the clearing the cache(s) that de-authenticated you. Sorry for any confusion I may have injected. Patrick -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
Hi Terry, > Stephen wrote: > > I think Ralph meant in the link he sent, which had the code from the > > Flask codebase for its version of HTTPBasicAuth. For basic auth it’s > > usually much simpler to use an .htaccess file, or with nginx the > > equivalent. > > Oh. OK. I understand that is the code the Flask method and not the > code for the Flask Development Server, but surely it's the server that > sets the cookie? > > As you can see, I have little idea how these things work. A browser sends an HTTP request and amongst the headers are zero or more Cookie ones for any cookies the browser had stored for the server's domain name. The web server passes those Cookie headers on to your code which is handling the request. https://flask.palletsprojects.com/en/1.1.x/quickstart/#cookies says To access cookies you can use the cookies attribute. When sending the reply from your code, through the web server, and back to the browser you may choose to set one or more cookies with the Set-Cookie header. These may be new cookies or existing ones. That Flask link again: To set cookies you can use the set_cookie method of response objects. But you're using HTTP Basic Authentication. https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication This doesn't use cookies. Instead, there is a WWW-Authenticate header from the server and a Authorization one from the browser. The implementation of those two can be done by the web server or your code. If the web server and it decides access is denied then your code never gets called. This is the ‘basic auth’ using .htaccess which Stephen mentions above and further explained at that mozilla.org page. The browser sees the challenge by the web server and puts up its own login-prompt box for username and password. If you want a nice web page for login then your code implements the test instead which is where your existing use of HTTPBasicAuth() from flask-HTTPAuth comes in. Either way, cookies aren't part of the mechanism, even if they may be present for other reasons which explains why clearing cookies didn't have a matching effect. Rewinding some months... - What's the website? - Does the whole site require authentication? - Are the users who need to authenticate a handful so they can be educated in responding to the browser's login prompt? - Do the users share devices provided at the site? - How long should a ‘login’ last? -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Tuesday, 26 January 2021 14:34:10 GMT Stephen Wolff wrote: > I think Ralph meant in the link he sent, which had the code from the > Flask codebase for its version of HTTPBasicAuth. For basic auth it’s > usually much simpler to use an .htaccess file, or with nginx the > equivalent. Oh. OK. I understand that is the code the Flask method and not the code for the Flask Development Server, but surely it's the server that sets the cookie? As you can see, I have little idea how these things work. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
What code on the server is setting a cookie? As I said above, I didn't spot HTTPBasicAuth updating a session, though perhaps I'm missing it. I think Ralph meant in the link he sent, which had the code from the Flask codebase for its version of HTTPBasicAuth. For basic auth it’s usually much simpler to use an .htaccess file, or with nginx the equivalent. -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Tuesday, 26 January 2021 14:14:23 GMT Ralph Corderoy wrote: > What code on the server is setting a cookie? As I said above, I didn't > spot HTTPBasicAuth updating a session, though perhaps I'm missing it. This is the Flask Development Server, so I don't know ;-( > Until the use of cookies by the site is better understood, it's hard to > reason about the risks of using cookies. :-) Once the site is deployed it will be running on nginx, where presumably I'll be able to configure it to do what I want / need. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
Hi Terry, > > Are you certain it uses the first example which is ‘HTTPBasicAuth’? > > It certainly is. > > > From > > https://github.com/miguelgrinberg/Flask-HTTPAuth/blob/master/flask_httpauth.py > > I don't spot that authentication method updating a session, unlike > > HTTPDigestAuth, for example. > > I believe that Hamish spotted the problem; it's a cookie issue. When > I cleared browsing data in Chromium, it made me log in again. What code on the server is setting a cookie? As I said above, I didn't spot HTTPBasicAuth updating a session, though perhaps I'm missing it. Until the use of cookies by the site is better understood, it's hard to reason about the risks of using cookies. :-) -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Tuesday, 26 January 2021 13:42:35 GMT Ralph Corderoy wrote: > In Firefox, ‘Tools → Web Developer → Network’ when viewing your page of > interest. Click ‘Reload’ so your page reloads and the new Network > window shows the traffic. > > Select a HTTP request of interest and in the new pane you'll see a > Headers tab which shows the Cookie headers in the request and the > Set-Cookie headers in the reply. The Cookies tab displays just them in > a broken-down format. It was working in Firefox so I tried to do the equivalent to what you suggest in Chromium. Presumably I should be able to see the cookies now I know how these developer tools work. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
Hi Terry, > Stephen wrote: > > You can view what cookies are stored in the ‘inspector’, so worth > > checking whether any are stored for an ‘http’ rather than ‘https’ > > connection. > > I'm assuming that this ‘inspector’ is accessed via the 'More tools - > Developer tools' Menu item. I tried that and couldn't see any cookies In Firefox, ‘Tools → Web Developer → Network’ when viewing your page of interest. Click ‘Reload’ so your page reloads and the new Network window shows the traffic. Select a HTTP request of interest and in the new pane you'll see a Headers tab which shows the Cookie headers in the request and the Set-Cookie headers in the reply. The Cookies tab displays just them in a broken-down format. -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Tuesday, 26 January 2021 13:34:10 GMT Ralph Corderoy wrote: > Are you certain it uses the first example which is ‘HTTPBasicAuth’? It certainly is. > From > https://github.com/miguelgrinberg/Flask-HTTPAuth/blob/master/flask_httpauth. > py I don't spot that authentication method updating a session, unlike > HTTPDigestAuth, for example. I believe that Hamish spotted the problem; it's a cookie issue. When I cleared browsing data in Chromium, it made me log in again. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
Hi Terry, > I have set up basic protection for my Minster Control Web page using > the information in the man page for flask-httpauth see: > > http://manpages.ubuntu.com/manpages/groovy/man1/flask-httpauth.1.html > > My App uses the code in the first example given and works fine Are you certain it uses the first example which is ‘HTTPBasicAuth’? From https://github.com/miguelgrinberg/Flask-HTTPAuth/blob/master/flask_httpauth.py I don't spot that authentication method updating a session, unlike HTTPDigestAuth, for example. -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Monday, 25 January 2021 14:51:59 GMT Patrick Wigmore wrote: > This means you can have a server-side time-out on the session, after > which the user's session cookie is worthless and they have to get a > new one by logging in anew. I'll look into that once I've deployed the server on the Pi. At present I'm testing the code using the Flask Development Server. > You can also have a log-out option on the web page, which will > instruct the server to terminate the session. I probably won't want to rely on the user doing this, so the server-side timeout option is probably the best approach. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Mon, 25 Jan 2021 13:41:57 +, Terry Coles wrote: > Since we can't force anyone to clear their cookies, I guess this > comes back to my original query; how unsafe is this? I can see > Hamish's point, the session cookie is only going to be stored on > the user's device, so if he keeps it safe, things should be OK. To large extent, it is the user's prerogative whether they keep the session cookie indefinitely. However, it is the web server's prerogative whether it will continue to accept the same session cookie indefinitely. A session cookie will only let you in for as long as the server thinks it corresponds to a valid session. This means you can have a server-side time-out on the session, after which the user's session cookie is worthless and they have to get a new one by logging in anew. You can also have a log-out option on the web page, which will instruct the server to terminate the session. This is applicable to the Web in general. I am afraid I don't know how you would implement a time-out or log-out feature in Flask specifically. It is possible there might already be a session time-out enabled by default in your server, but it could be many days long. So the question is whether long-lasting sessions are a risk or not, and that depends on the application. In this case, I'd guess the chances and consequences of someone using the session cookie to gain unauthorised access will be relatively limited. Patrick -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Monday, 25 January 2021 13:04:08 GMT Stephen Wolff wrote: > It might be an issue with ‘https’, as Chrome is very fussy about > this nowadays. Not sure whether Chromium is the same, but it is likely > to be. Hmmm. When I did the original Web Server at WMT (Audio Guide, Kiddies Quiz,etc), I tried setting it up with Self-Signed Certificates, but Chrome on Android didn't like them. > You can view what cookies are stored in the ‘inspector’, so worth > checking whether any are stored for an ‘http’ rather than > ‘https’ connection. I'm assuming that this ‘inspector’ is accessed via the 'More tools - Developer tools' Menu item. I tried that and couldn't see any cookies, although they are visible in the main Settings Page. I tried clearing Browsing data and worked. I didn't even have to close the browser. When I went back to the Control Page, I was prompted for my credentials. Since we can't force anyone to clear their cookies, I guess this comes back to my original query; how unsafe is this? I can see Hamish's point, the session cookie is only going to be stored on the user's device, so if he keeps it safe, things should be OK. Any comments on this? -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
I imagine this will be to do with the cookie and session cookie settings you have set for those browsers. My guess is you have Firefox set to clear them when closed, but not with Chromium. Store cookies *was* on in Chromium and off in Firefox. Turning it off in Chromium didn't stop the behaviour. BTW. I get the same behaviour with Konquerer and it doesn't seem to have any Settings relevant to cookies (or anything else much). It might be an issue with ‘https’, as Chrome is very fussy about this nowadays. Not sure whether Chromium is the same, but it is likely to be. You can view what cookies are stored in the ‘inspector’, so worth checking whether any are stored for an ‘http’ rather than ‘https’ connection. -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On Monday, 25 January 2021 12:39:24 GMT Hamish McIntyre-Bhatty wrote: > I imagine this will be to do with the cookie and session cookie settings > you have set for those browsers. My guess is you have Firefox set to > clear them when closed, but not with Chromium. Store cookies *was* on in Chromium and off in Firefox. Turning it off in Chromium didn't stop the behaviour. BTW. I get the same behaviour with Konquerer and it doesn't seem to have any Settings relevant to cookies (or anything else much). > Whether this is an issue depends on how you judge the situation to be, > but also how long it takes for the login cookie to expire. The longer it > takes for it to expire, the bigger the risk of someone getting access if > they eg pocket someone's device. The trouble is that we will have no control over the settings for a Staff Member's device. Having said that, the thief would have to not only be a scrote but also know about browsers etc; probably not a common situation. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
On 25/01/2021 12:34, Terry Coles wrote: > Hi, > > I have set up basic protection for my Minster Control Web page using the > information in the man page for flask-httpauth see: > > http://manpages.ubuntu.com/manpages/groovy/man1/flask-httpauth.1.html > > My App uses the code in the first example given and works fine, except that > if I > log in to my secured page using Chromium, I am never challenged for the > password after the first login, even after I have shut down the browser. If > I > log in with Firefox, everything is good, ie, once logged in, I can re-enter > the page without being challenged again until I shut down the browser. In > that instance I am challenged again when I surf to the protected page. > > Chromium has not saved the password. > > Can anyone explain what is going on and is this likely to be a security issue? I imagine this will be to do with the cookie and session cookie settings you have set for those browsers. My guess is you have Firefox set to clear them when closed, but not with Chromium. Whether this is an issue depends on how you judge the situation to be, but also how long it takes for the login cookie to expire. The longer it takes for it to expire, the bigger the risk of someone getting access if they eg pocket someone's device. Hamish signature.asc Description: OpenPGP digital signature -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
[Dorset] Problem using Chromium to log in to Web Page Secured with flask-httpauth
Hi, I have set up basic protection for my Minster Control Web page using the information in the man page for flask-httpauth see: http://manpages.ubuntu.com/manpages/groovy/man1/flask-httpauth.1.html My App uses the code in the first example given and works fine, except that if I log in to my secured page using Chromium, I am never challenged for the password after the first login, even after I have shut down the browser. If I log in with Firefox, everything is good, ie, once logged in, I can re-enter the page without being challenged again until I shut down the browser. In that instance I am challenged again when I surf to the protected page. Chromium has not saved the password. Can anyone explain what is going on and is this likely to be a security issue? -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-02-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
