From slitt at troubleshooters.com Tue Dec 6 20:38:06 2022 From: slitt at troubleshooters.com (Steve Litt) Date: Tue, 6 Dec 2022 13:38:06 -0500 Subject: GoLUG meeting features Python threads and thread discussion Message-ID: <20221206133806.77ca980c@mydesk.domain.cxm> Hi all, The Wednesday, December 7, 2022 GoLUG start at 7pm Eastern Standard time. It will be at https://meet.jit.si/golug. Full information is at http://golug.info. Come Join us on December 7th, for an introductory course to Go. No experience required, we'll cover some of the basics of Go syntax, learn how to write some very simple basic programs ending with a demonstration of a fully functional opinionated code base for a RESTFul service written in Go. If you wish to follow along, please make sure you have VSCode and Go installed ( https://go.dev/doc/install). Ensure that you have GOROOT, GOPATH and your $PATH have all been updated in order to at least be able to run: `go version` from the command line. NOTE: After installing Go, first try running `go version` because on some distros it runs without GOROOT or GOPATH. The first ten minutes will be devoted to setting GOROOT and GOPATH, so please be sure to be in this Jitsi meeting by 7PM Eastern Standard Time sharp. SteveT Steve Litt GoLUG Publicity Coordinator From slitt at troubleshooters.com Tue Dec 6 21:14:20 2022 From: slitt at troubleshooters.com (Steve Litt) Date: Tue, 6 Dec 2022 14:14:20 -0500 Subject: CORRECTION: GoLUG meeting topic Message-ID: <20221206141420.47ec5fb1@mydesk.domain.cxm> Hi all, The correct topic for the GoLUG meeting is "Introduction to Go Language". Sorry for the error in the subject of the initial announcement. SteveT Steve Litt GoLUG Publicity Coordinator From w1 at zak.co.il Mon Dec 19 03:57:25 2022 From: w1 at zak.co.il (Omer Zak) Date: Mon, 19 Dec 2022 03:57:25 +0200 Subject: How to get wget to fail to fetch a password-protected URL after a previous success? Message-ID: <39239374d9dd26558341dcdf3679b7c0c8248fb9.camel@zak.co.il> 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? Thanks, --- Omer Zak -- "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 From shlomif at shlomifish.org Mon Dec 19 05:37:30 2022 From: shlomif at shlomifish.org (Shlomi Fish) Date: Mon, 19 Dec 2022 05:37:30 +0200 Subject: How to get wget to fail to fetch a password-protected URL after a previous success? In-Reply-To: <39239374d9dd26558341dcdf3679b7c0c8248fb9.camel@zak.co.il> References: <39239374d9dd26558341dcdf3679b7c0c8248fb9.camel@zak.co.il> Message-ID: <20221219053730.0c44c2af@shlomifish.org> Hi Omer! On Mon, 19 Dec 2022 03:57:25 +0200 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 suspect the stale cache is on the webservice or on a proxy. Also note that python3 has requests.py: https://github.com/shlomif/Freenode-programming-channel-FAQ/blob/master/FAQ_with_ToC__generated.md#how-can-i-write-code-to-perform-operations-on-web-sites-for-me-that-otherwise-should-be-done-manually (short url: https://is.gd/ExAHTa ) > 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? > > Thanks, > --- Omer Zak > > -- Shlomi Fish https://www.shlomifish.org/ https://www.shlomifish.org/open-source/resources/tech-tips/ Ever notice that even the busiest people are never too busy to tell you just how busy they are? ? Source unknown, taken from Linux?s fortune-mod Please reply to list if it's a mailing list post - https://shlom.in/reply . From guy.choo.keren at gmail.com Mon Dec 19 10:10:23 2022 From: guy.choo.keren at gmail.com (guy keren) Date: Mon, 19 Dec 2022 10:10:23 +0200 Subject: How to get wget to fail to fetch a password-protected URL after a previous success? In-Reply-To: <39239374d9dd26558341dcdf3679b7c0c8248fb9.camel@zak.co.il> References: <39239374d9dd26558341dcdf3679b7c0c8248fb9.camel@zak.co.il> Message-ID: 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? > > Thanks, > --- Omer Zak > > From w1 at zak.co.il Mon Dec 19 11:11:27 2022 From: w1 at zak.co.il (Omer Zak) Date: Mon, 19 Dec 2022 11:11:27 +0200 Subject: Solved (Re: How to get wget to fail to fetch a password-protected URL after a previous success?) In-Reply-To: References: <39239374d9dd26558341dcdf3679b7c0c8248fb9.camel@zak.co.il> Message-ID: 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 From shachar at shemesh.biz Wed Dec 21 18:22:36 2022 From: shachar at shemesh.biz (Shachar Shemesh) Date: Wed, 21 Dec 2022 18:22:36 +0200 Subject: Job offer: Looking for a Linux kernel driver developer Message-ID: <0317a252-dbac-dc8d-0e26-31967ee07542@shemesh.biz> An HTML attachment was scrubbed... URL: