Solved (Re: How to get wget to fail to fetch a password-protected URL after a previous success?)

[Omer Zak]

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