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
