I solved the problem. Turns out that I used the wrong format of a location directive in a Nginx configuration.
The offending stanza was: location = /p2mb { root /usr/share/nginx/html/stuff; auth_basic "P2MB Stuff"; auth_basic_user_file /etc/nginx/auth-basic-passwords-p2mb; } The correct stanza is: location /p2mb { root /usr/share/nginx/html/stuff; auth_basic "P2MB Stuff"; auth_basic_user_file /etc/nginx/auth-basic-passwords-p2mb; } And I did not notice that I was using different URLs in my tests (it was late at night :-) ). I experimented with both wget http://somehostname/p2mb (is blocked by both stanzas) and wget http://somehostname/p2mb/somefile.ext (is blocked only by the second stanza) Thanks to those who tried to help me both on Linux-IL mailing list and privately. In the big scheme of things, my effort to develop tests for the website did uncover a bug - the above mistake in the location directive. bats-core (https://github.com/bats-core/bats-core) kicks ass! --- Omer On Mon, 2022-12-19 at 10:10 +0200, guy keren wrote: > > use 'strace' to try to locate where it might be storing the > credentials. > > --guy > > On 12/19/22 03:57, Omer Zak wrote: > > I am writing regression tests to test that a website continues to > > behave the same after moving to another host. > > > > Among other things, I want to test that a password-protected area > > in > > the website continues to work as expected, protecting its contents. > > > > I am trying to test as follows. > > > > wget ...other options... URL > > # no passwords - expected to fail > > wget --user=wrong --password=wrong ...other options... URL > > # expected to fail > > wget --user=correct --password=correct ...other options... URL > > # expected to succeed > > > > However after 1st time the correct user+password are presented, > > subsequent wget's to the same URL do not fail. > > > > I Googled but found nothing useful. > > My version of wget is: GNU Wget 1.21 built on linux-gnu. > > (there is more information, will be provided if relevant) > > > > At the suggestion of: > > https://stackoverflow.com/questions/35076334/dd-wrt-wget-returns-a-cached-file > > I tried: > > wget -p --no-http-keep-alive --no-cache --no-cookies \ > > --user=whatever --password=whatever > > --no-host-directories URL > > Even this did not fail. > > > > There is no obvious place in the filesystem where wget might cache > > its > > credentials. > > > > How can I get wget to fail to fetch a password-protected web > > resource > > (HTTP 403 Forbidden) after it succeeded in fetching the same > > resource > > previously? -- "Prior to capitalism, the way people amassed great wealth was by looting, plundering and enslaving their fellow man. Capitalism made it possible to become wealthy by serving your fellow man." - Walter E. Williams My own blog is at https://tddpirate.zak.co.il/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at https://www.zak.co.il/spamwarning.html _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il