Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
wget and captcha puzzle !!!
640 views
Skip to first unread message
J. Bakshi
Jan 21, 2012, 11:10:02 AM1/21/12
to
Dear list,
My internet provider provides an online form accessed by local IP (the connection
is based on eth); so that the subscriber can provide username and password to activate
the login; additionally it also has a captcha as added security. I am trying to make a
daemon which just do the login and activate the connection. Within the source of the
form the captcha link embedded as src="http://192.168.1.108/captcha.phtml?r=003665dd765d04967a7e00071e6af4a1"
And the long string at end changes everytime I reload the form.
Anyways I can read the captcha code with
```````````
#!/bin/bash
wget http://192.168.1.108
#extract the captcha string like captcha.phtml?r=72eb74eb980688ae730dbb9cb7d6a5d8
cap_string=`cat index.php | grep src=\"captcha.phtml | cut -f 10 -d '"'`
wget http://192.168.1.108/$cap_string -O /tmp/captcha.png
gocr /tmp/captcha.png
`````````````
And it really do the tricks, reading the captcha :-)
Though sending the same code through wget along-with username and password doesn't work.
wget --post-date 'username=xxx&password=xxx&captcha_code=<retrieved_code>' http://192.168.1.108
*BECAUSE*
If I visit the url http://192.168.1.108/captcha.phtml?r=003665dd765d04967a7e00071e6af4a1
again and again; every time I get a new captcha. So when I submitting the captcha
by wget; it is already changes to a new one !!!! How can I overcome this puzzle ?
The form (through browser) gives a failure notice when captcha code doesn't match. Is it possible to collect
the failure notice through wget somehow for debugging ?
Please give me some clue. I just like my linux script do the login and activate internet.
Thanks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120121213...@shiva.selfip.org
My internet provider provides an online form accessed by local IP (the connection
is based on eth); so that the subscriber can provide username and password to activate
the login; additionally it also has a captcha as added security. I am trying to make a
daemon which just do the login and activate the connection. Within the source of the
form the captcha link embedded as src="http://192.168.1.108/captcha.phtml?r=003665dd765d04967a7e00071e6af4a1"
And the long string at end changes everytime I reload the form.
Anyways I can read the captcha code with
```````````
#!/bin/bash
wget http://192.168.1.108
#extract the captcha string like captcha.phtml?r=72eb74eb980688ae730dbb9cb7d6a5d8
cap_string=`cat index.php | grep src=\"captcha.phtml | cut -f 10 -d '"'`
wget http://192.168.1.108/$cap_string -O /tmp/captcha.png
gocr /tmp/captcha.png
`````````````
And it really do the tricks, reading the captcha :-)
Though sending the same code through wget along-with username and password doesn't work.
wget --post-date 'username=xxx&password=xxx&captcha_code=<retrieved_code>' http://192.168.1.108
*BECAUSE*
If I visit the url http://192.168.1.108/captcha.phtml?r=003665dd765d04967a7e00071e6af4a1
again and again; every time I get a new captcha. So when I submitting the captcha
by wget; it is already changes to a new one !!!! How can I overcome this puzzle ?
The form (through browser) gives a failure notice when captcha code doesn't match. Is it possible to collect
the failure notice through wget somehow for debugging ?
Please give me some clue. I just like my linux script do the login and activate internet.
Thanks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120121213...@shiva.selfip.org
J. Bakshi
Jan 21, 2012, 11:30:02 AM1/21/12
to
On Sat, 21 Jan 2012 16:21:45 +0000 (UTC)
Camaleón <noel...@gmail.com> wrote:
> On Sat, 21 Jan 2012 21:39:25 +0530, J. Bakshi wrote:
>
> > My internet provider provides an online form accessed by local IP (the
> > connection is based on eth); so that the subscriber can provide username
> > and password to activate the login; additionally it also has a captcha
> > as added security. I am trying to make a daemon which just do the login
> > and activate the connection.
>
> (...)
> cookie or some kind of time-based script in place. Not sure how to bypass
> that, it will depend on how the page is coded :-?
>
> I would first try to keep all those wget steps in just one session by
> capturing the cookie (if any) that stores the session ID.
>
> Greetings,
>
Hello Camaleón,
Thanks for your suggestion. But I don't know if there is any cookie at all.
I just observe through browser, If I visit the same link next time or refresh;
I get a new captcha code. And the embedded captcha string also changes when
open or reload the login form. So when I download the captcha, that very step also
reload a new captcha. How can I know if there is any cookie responsible
for that session ?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120121215...@shiva.selfip.org
Camaleón <noel...@gmail.com> wrote:
> On Sat, 21 Jan 2012 21:39:25 +0530, J. Bakshi wrote:
>
> > My internet provider provides an online form accessed by local IP (the
> > connection is based on eth); so that the subscriber can provide username
> > and password to activate the login; additionally it also has a captcha
> > as added security. I am trying to make a daemon which just do the login
> > and activate the connection.
>
>
> > If I visit the url
> > http://192.168.1.108/captcha.phtml?r=003665dd765d04967a7e00071e6af4a1
> > again and again; every time I get a new captcha. So when I submitting
> > the captcha by wget; it is already changes to a new one !!!! How can I
> > overcome this puzzle ? The form (through browser) gives a failure notice
> > when captcha code doesn't match. Is it possible to collect the failure
> > notice through wget somehow for debugging ?
> >
> > Please give me some clue. I just like my linux script do the login and
> > activate internet. Thanks
>
> If the captcha code auto-reloads it could be due to a session tracking
> > If I visit the url
> > http://192.168.1.108/captcha.phtml?r=003665dd765d04967a7e00071e6af4a1
> > again and again; every time I get a new captcha. So when I submitting
> > the captcha by wget; it is already changes to a new one !!!! How can I
> > overcome this puzzle ? The form (through browser) gives a failure notice
> > when captcha code doesn't match. Is it possible to collect the failure
> > notice through wget somehow for debugging ?
> >
> > Please give me some clue. I just like my linux script do the login and
> > activate internet. Thanks
>
> cookie or some kind of time-based script in place. Not sure how to bypass
> that, it will depend on how the page is coded :-?
>
> I would first try to keep all those wget steps in just one session by
> capturing the cookie (if any) that stores the session ID.
>
> Greetings,
>
Hello Camaleón,
Thanks for your suggestion. But I don't know if there is any cookie at all.
I just observe through browser, If I visit the same link next time or refresh;
I get a new captcha code. And the embedded captcha string also changes when
open or reload the login form. So when I download the captcha, that very step also
reload a new captcha. How can I know if there is any cookie responsible
for that session ?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
Jan 21, 2012, 11:30:02 AM1/21/12
to
On Sat, 21 Jan 2012 21:39:25 +0530, J. Bakshi wrote:
> My internet provider provides an online form accessed by local IP (the
> connection is based on eth); so that the subscriber can provide username
> and password to activate the login; additionally it also has a captcha
> as added security. I am trying to make a daemon which just do the login
> and activate the connection.
(...)
> connection is based on eth); so that the subscriber can provide username
> and password to activate the login; additionally it also has a captcha
> as added security. I am trying to make a daemon which just do the login
> and activate the connection.
> If I visit the url
> http://192.168.1.108/captcha.phtml?r=003665dd765d04967a7e00071e6af4a1
> again and again; every time I get a new captcha. So when I submitting
> the captcha by wget; it is already changes to a new one !!!! How can I
> overcome this puzzle ? The form (through browser) gives a failure notice
> when captcha code doesn't match. Is it possible to collect the failure
> notice through wget somehow for debugging ?
>
> Please give me some clue. I just like my linux script do the login and
> activate internet. Thanks
If the captcha code auto-reloads it could be due to a session tracking
cookie or some kind of time-based script in place. Not sure how to bypass
that, it will depend on how the page is coded :-?
I would first try to keep all those wget steps in just one session by
capturing the cookie (if any) that stores the session ID.
Greetings,
--
cookie or some kind of time-based script in place. Not sure how to bypass
that, it will depend on how the page is coded :-?
I would first try to keep all those wget steps in just one session by
capturing the cookie (if any) that stores the session ID.
Greetings,
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bob Proulx
Jan 21, 2012, 11:50:01 AM1/21/12
to
J. Bakshi wrote:
> cap_string=`cat index.php | grep src=\"captcha.phtml | cut -f 10 -d '"'`
Search the web for "useless use of cat" and read all about it. Don't
> cap_string=`cat index.php | grep src=\"captcha.phtml | cut -f 10 -d '"'`
use cat piped to grep here. Simply use grep.
Plus I recommend getting in the habit of using $(...) instead of `...`.
cap_string=$(grep src=\"captcha.phtml index.php | cut -f 10 -d '"')
The site is almost certainly using session cookies to create a virtual
connection. Read the wget man page for the cookies options.
Basically something like this:
wget --keep-session-cookies --save-cookies=cookies.txt http://192.168.1.108/$cap_string -O /tmp/captcha.png
wget --keep-session-cookies --load-cookies=cookies.txt --save-cookies=cookies.txt --post-date 'username=xxx&password=xxx&captcha_code=<retrieved_code>' http://192.168.1.108
That should tell wget to save the session cookies to the file and then
with the next invocation will load those session cookies and send them
back to the site. This should enable the separate wget invocations to
appear as a single session client to the remote web site.
Bob
Camaleón
Jan 21, 2012, 11:50:02 AM1/21/12
to
On Sat, 21 Jan 2012 21:58:58 +0530, J. Bakshi wrote:
> On Sat, 21 Jan 2012 16:21:45 +0000 (UTC) Camaleón <noel...@gmail.com>
> wrote:
(...)
>> > If I visit the url
>> > http://192.168.1.108/captcha.phtml?r=003665dd765d04967a7e00071e6af4a1
>> > again and again; every time I get a new captcha. So when I submitting
>> > the captcha by wget; it is already changes to a new one !!!! How can
>> > I overcome this puzzle ? The form (through browser) gives a failure
>> > notice when captcha code doesn't match. Is it possible to collect the
>> > failure notice through wget somehow for debugging ?
>> >
>> > Please give me some clue. I just like my linux script do the login
>> > and activate internet. Thanks
>>
>> If the captcha code auto-reloads it could be due to a session tracking
>> cookie or some kind of time-based script in place. Not sure how to
>> bypass that, it will depend on how the page is coded :-?
>>
>> I would first try to keep all those wget steps in just one session by
>> capturing the cookie (if any) that stores the session ID.
>>
>
> On Sat, 21 Jan 2012 16:21:45 +0000 (UTC) Camaleón <noel...@gmail.com>
> wrote:
(...)
>> > If I visit the url
>> > http://192.168.1.108/captcha.phtml?r=003665dd765d04967a7e00071e6af4a1
>> > again and again; every time I get a new captcha. So when I submitting
>> > the captcha by wget; it is already changes to a new one !!!! How can
>> > I overcome this puzzle ? The form (through browser) gives a failure
>> > notice when captcha code doesn't match. Is it possible to collect the
>> > failure notice through wget somehow for debugging ?
>> >
>> > Please give me some clue. I just like my linux script do the login
>> > and activate internet. Thanks
>>
>> If the captcha code auto-reloads it could be due to a session tracking
>> cookie or some kind of time-based script in place. Not sure how to
>> bypass that, it will depend on how the page is coded :-?
>>
>> I would first try to keep all those wget steps in just one session by
>> capturing the cookie (if any) that stores the session ID.
>>
>
> Thanks for your suggestion. But I don't know if there is any cookie at
> all. I just observe through browser, If I visit the same link next time
> or refresh; I get a new captcha code. And the embedded captcha string
> also changes when open or reload the login form. So when I download the
> captcha, that very step also reload a new captcha. How can I know if
> there is any cookie responsible for that session ?
You have to read the html code of the page... and know how to interpret
> all. I just observe through browser, If I visit the same link next time
> or refresh; I get a new captcha code. And the embedded captcha string
> also changes when open or reload the login form. So when I download the
> captcha, that very step also reload a new captcha. How can I know if
> there is any cookie responsible for that session ?
it (you need to know some of the basics of html and javascript
language) :-)
Or you can load the page from firefox (or any other browser that can
display such information) right-click over it and choose "View page
information". If the site tries to set a cookie it will be listed under
"Security" tab.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
John Hasler
Jan 21, 2012, 12:00:01 PM1/21/12
to
> So when I download the captcha, that very step also reload a new
> captcha.
If the captcha has been properly implemented there's no way around
> captcha.
solving it. Look at:
Package: slimrat-nox
Source: slimrat
Version: 1.0-1
Installed-Size: 336
Maintainer: Paul McEnery <pmce...@gmail.com>
Architecture: all
Depends: perl, libwww-perl, libwww-mechanize-perl, libcrypt-ssleay-perl, aview, imagemagick, tesseract-ocr
Description: CLI application for automated downloading from file hosters
Provides a command-line interface for automatically downloading files
from hosting providers. Slimrat is also capable of captcha solving using
tesseract for optical character recognition. Support includes, but is
not limited to the following file hosters:
.
* data.hu
* www.depositfiles.com
* www.easy-share.com
* www.fast-load.net
* www.fast-share.com
* www.hotfile.com
* leteckaposta.cz
* www.mediafire.com
* www.megaupload.com
* odsiebie.najlepsze.net
* www.rapidshare.com
* sharebase.to
* uploaded.to
* www.youtube.com
.
This package provides the command-line user interface
Homepage: http://code.google.com/p/slimrat/
And:
Package: tesseract-ocr
Priority: optional
Section: graphics
Installed-Size: 3184
Maintainer: Jeffrey Ratcliffe <Jeffrey....@gmail.com>
Architecture: amd64
Source: tesseract
Version: 2.04-2+squeeze1
Replaces: tesseract-ocr-data
Depends: libc6 (>= 2.2.5), libgcc1 (>= 1:4.1.1), libjpeg62 (>= 6b1), libstdc++6 (>= 4.1.1), libtiff4, zlib1g (>= 1:1.1.4), tesseract-ocr-eng | tesseract-ocr-language
Filename: pool/main/t/tesseract/tesseract-ocr_2.04-2+squeeze1_amd64.deb
Size: 1026476
MD5sum: 4391d9a7cc1e1ff13996ec2011bf8f9a
SHA1: bfaa49414b480c30661973d6d0fc7be9794ca0e9
SHA256: ac6738f86e353d7e2cff9ebfcc4f29dbacbdd4b3abf5088bd89d066f6c65468a
Description: Command line OCR tool
The Tesseract OCR engine was originally developed at HP between 1985 and 1995.
It was open-sourced by HP and UNLV in 2005 and Google has lead further
development.
.
The Tesseract OCR engine was one of the top 3 engines in the 1995 UNLV
Accuracy test. Between 1995 and 2006 it had little work done on it, but it
is probably one of the most accurate open source OCR engines available. It
will read a binary, grey or color image and output text.
Homepage: http://code.google.com/p/tesseract-ocr/
--
John Hasler
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
John Hasler
Jan 21, 2012, 12:00:02 PM1/21/12
to
Bob writes:
> This should enable the separate wget invocations to appear as a single
> session client to the remote web site.
But he'll still have to solve the captcha to establish the session.
> This should enable the separate wget invocations to appear as a single
> session client to the remote web site.
--
John Hasler
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jude DaShiell
Jan 21, 2012, 12:10:01 PM1/21/12
to
1) locate and crush all cookies,
2) adjust browser settings so no cookies are allowed on your machine,
3) attempt another connection and see if the session bitches about no
cookies being accepted. If yes, then you have your proof otherwise
something else is happening. Personally, I'll loose any internet
provider that even considers doing what yours has done in a New York
Minute. Depending on where your internet provider is located, that
captcha may constitute a violation of the Americans With Disabilities
Act since your internet service provider provides a service to the
public it then becomes equivalent to a public accommodation.
> Hello Camale?n,
Jude <jdashiel-at-shellworld-dot-net>
<http://www.shellworld.net/~jdashiel/nj.html>
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/alpine.BSF.2.01.1...@freire1.furyyjbeyq.arg
2) adjust browser settings so no cookies are allowed on your machine,
3) attempt another connection and see if the session bitches about no
cookies being accepted. If yes, then you have your proof otherwise
something else is happening. Personally, I'll loose any internet
provider that even considers doing what yours has done in a New York
Minute. Depending on where your internet provider is located, that
captcha may constitute a violation of the Americans With Disabilities
Act since your internet service provider provides a service to the
public it then becomes equivalent to a public accommodation.
>
> Thanks for your suggestion. But I don't know if there is any cookie at all.
> I just observe through browser, If I visit the same link next time or refresh;
> I get a new captcha code. And the embedded captcha string also changes when
> open or reload the login form. So when I download the captcha, that very step also
> reload a new captcha. How can I know if there is any cookie responsible
> for that session ?
>
>
> --
> To UNSUBSCRIBE, email to debian-us...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/20120121215...@shiva.selfip.org
>
>
----------------------------------------------------------------
> Thanks for your suggestion. But I don't know if there is any cookie at all.
> I just observe through browser, If I visit the same link next time or refresh;
> I get a new captcha code. And the embedded captcha string also changes when
> open or reload the login form. So when I download the captcha, that very step also
> reload a new captcha. How can I know if there is any cookie responsible
> for that session ?
>
>
> --
> To UNSUBSCRIBE, email to debian-us...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/20120121215...@shiva.selfip.org
>
>
Jude <jdashiel-at-shellworld-dot-net>
<http://www.shellworld.net/~jdashiel/nj.html>
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tony Baldwin
Jan 21, 2012, 12:20:02 PM1/21/12
to
On Sat, Jan 21, 2012 at 10:59:21AM -0600, John Hasler wrote:
> Bob writes:
> > This should enable the separate wget invocations to appear as a single
> > session client to the remote web site.
>
> But he'll still have to solve the captcha to establish the session.
Indeed.
> Bob writes:
> > This should enable the separate wget invocations to appear as a single
> > session client to the remote web site.
>
> But he'll still have to solve the captcha to establish the session.
Isn't the whole point of using captcha to prevent automated access to
stuff? (ie. require human interaction).
Sort of OT, but mentioned in this thread,
Why use $(command) instead of `command`?
Generally, I've always used $(command), but see scripts all over using
`command`, and wondered if there were advantages of one over the other.
It seems they give the same result, no?
./tony
--
http://www.tonybaldwin.me
all tony, all the time!
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
John Hasler
Jan 21, 2012, 12:40:01 PM1/21/12
to
J. Bakshi writes:
> My internet provider provides an online form accessed by local IP (the
> connection is based on eth); so that the subscriber can provide
> username and password to activate the login; additionally it also has
> a captcha as added security.
Do you mean that you need to do this to access some Web page of theirs
> My internet provider provides an online form accessed by local IP (the
> connection is based on eth); so that the subscriber can provide
> username and password to activate the login; additionally it also has
> a captcha as added security.
that is of interest, or that you must do this every time you establish
an Internet connection? If the latter they are complete loons.
--
John Hasler
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
J. Bakshi
Jan 21, 2012, 12:40:02 PM1/21/12
to
On Sat, 21 Jan 2012 10:59:21 -0600
John Hasler <jha...@newsguy.com> wrote:
> Bob writes:
> > This should enable the separate wget invocations to appear as a single
> > session client to the remote web site.
>
> But he'll still have to solve the captcha to establish the session.
That's why I have gocr
John Hasler <jha...@newsguy.com> wrote:
> Bob writes:
> > This should enable the separate wget invocations to appear as a single
> > session client to the remote web site.
>
> But he'll still have to solve the captcha to establish the session.
[...]
gocr /tmp/captcha.png
[...]
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
J. Bakshi
Jan 21, 2012, 12:50:02 PM1/21/12
to
On Sat, 21 Jan 2012 16:45:46 +0000 (UTC)
I have very little knowledge on html and javascript. And I'm really thankful to you
for your kind guidance. Following your tips I have seen there is indeed a cookie.
NAME: PHPSESSID
Content: 6cfd4a0b968778714d093d66a66b92a5
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120121231...@shiva.selfip.org
for your kind guidance. Following your tips I have seen there is indeed a cookie.
NAME: PHPSESSID
Content: 6cfd4a0b968778714d093d66a66b92a5
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bob Proulx
Jan 21, 2012, 12:50:02 PM1/21/12
to
Tony Baldwin wrote:
> John Hasler wrote:
> > Bob writes:
> > > This should enable the separate wget invocations to appear as a single
> > > session client to the remote web site.
> >
> > But he'll still have to solve the captcha to establish the session.
Yes. But J said he had that part working okay and without any other
> John Hasler wrote:
> > Bob writes:
> > > This should enable the separate wget invocations to appear as a single
> > > session client to the remote web site.
> >
> > But he'll still have to solve the captcha to establish the session.
conflicting information I will take him at his word. :-)
> Indeed.
> Isn't the whole point of using captcha to prevent automated access to
> stuff? (ie. require human interaction).
battle between the opposing forces. And it isn't always clear which
is on the side of Good and which is on the side of Evil. Sometimes it
is the Not So Good and the Somewhat Less Good.
> Sort of OT, but mentioned in this thread,
> Why use $(command) instead of `command`?
> Generally, I've always used $(command), but see scripts all over using
> `command`, and wondered if there were advantages of one over the other.
> It seems they give the same result, no?
and replacing the output from it onto the command line. It is the
oldest method and in the simple case works everywhere. However the
quoting rules are difficult. Quoting includes both double and single
quotes and also includes nested `...` statements within `...`
statements. There is always a quoting solution but it can be tedious
to create correctly.
The $(...) is newer syntax from ksh (newer from 1986 or so) which was
standardized into POSIX and therefore all POSIX shells will support
it. The use of matching parenthesis means that nesting of commands is
simpler. Most importantly the quoting rules are regular throughout.
You can even nest $(...) inside of $(...). For example: $(... $(...) )
The simpler and regular quoting rules wins the choice for me.
Bob
Bob Proulx
Jan 21, 2012, 1:00:02 PM1/21/12
to
John Hasler wrote:
> J. Bakshi writes:
> > My internet provider provides an online form accessed by local IP (the
> > connection is based on eth); so that the subscriber can provide
> > username and password to activate the login; additionally it also has
> > a captcha as added security.
>
> Do you mean that you need to do this to access some Web page of theirs
> that is of interest, or that you must do this every time you establish
> an Internet connection? If the latter they are complete loons.
I have been weeks at locations where there only available networking
> J. Bakshi writes:
> > My internet provider provides an online form accessed by local IP (the
> > connection is based on eth); so that the subscriber can provide
> > username and password to activate the login; additionally it also has
> > a captcha as added security.
>
> Do you mean that you need to do this to access some Web page of theirs
> that is of interest, or that you must do this every time you establish
> an Internet connection? If the latter they are complete loons.
was from commercial wide area wifi providers who required every
initiation of connection this way. They were doing filtering based
upon ethernet address and required me to authenticate so that they
would register the MAC address of the machine. It was extremely
annoying! From their point of view they are covering a wide area and
they wanted to prevent abuse from script kiddies. Though it was very
"hackishly" implemented for a commercial service. From my point of
view I was purchasing a week's network connectivity, had already spent
the money, and it was either use it or lose it. And there weren't any
other choices available.
Fortunately I was running a WRT54GL which was always on and so I could
authenticate once for it and it would stay connected due to the
constant trickle of network activity and then only need to repeat it
manually when things failed and needed to be restarted. For me that
was a few times through the course of the couple of weeks and so I
just muscled through it. But I know that if I had been dealing with
them long term I would have considered automating the process.
Bob
J. Bakshi
Jan 21, 2012, 1:00:02 PM1/21/12
to
On Sat, 21 Jan 2012 11:31:19 -0600
John Hasler <jha...@newsguy.com> wrote:
> J. Bakshi writes:
> > My internet provider provides an online form accessed by local IP (the
> > connection is based on eth); so that the subscriber can provide
> > username and password to activate the login; additionally it also has
> > a captcha as added security.
>
> Do you mean that you need to do this to access some Web page of theirs
> that is of interest, or that you must do this every time you establish
> an Internet connection? If the latter they are complete loons.
Yes, everytime when establishing a connection.
John Hasler <jha...@newsguy.com> wrote:
> J. Bakshi writes:
> > My internet provider provides an online form accessed by local IP (the
> > connection is based on eth); so that the subscriber can provide
> > username and password to activate the login; additionally it also has
> > a captcha as added security.
>
> Do you mean that you need to do this to access some Web page of theirs
> that is of interest, or that you must do this every time you establish
> an Internet connection? If the latter they are complete loons.
And I like to automate the process with a script.
The main hitch with that captcha
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
John Hasler
Jan 21, 2012, 1:10:02 PM1/21/12
to
Bob writes:
> This should enable the separate wget invocations to appear as a single
> session client to the remote web site.
> This should enable the separate wget invocations to appear as a single
> session client to the remote web site.
I wrote:
> But he'll still have to solve the captcha to establish the session.
> But he'll still have to solve the captcha to establish the session.
J. Bakshi writes:
> That's why I have gocr
Then you should be all set. You just have to accept the session cookie
> That's why I have gocr
so that their server knows it's you when you send requests after solving
the captcha.
Look at the `--load-cookies FILE' option on the wget man page. Read the
entire section about cookies.
--
John Hasler
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mathias Bauer
Jan 21, 2012, 1:10:02 PM1/21/12
to
* Tony Baldwin wrote on 2012-01-21 at 12:15 (-0500):
> Why use $(command) instead of `command`?
> Generally, I've always used $(command), but see scripts all
> over using `command`, and wondered if there were advantages of
> one over the other. It seems they give the same result, no?
Some do, some don't :-) See some curious examples on
> Why use $(command) instead of `command`?
> Generally, I've always used $(command), but see scripts all
> over using `command`, and wondered if there were advantages of
> one over the other. It seems they give the same result, no?
http://tldp.org/LDP/abs/html/commandsub.html
For short, I think you should use $(...) and try to avoid `...`.
Also keep in mind that in Debian /bin/sh -> dash
----------test1.sh----------
#!/bin/sh
set -xv
echo `echo \\`
echo $(echo \\)
----------------------------
$ ./test1.sh <-------- same output as dash ./test1.sh
echo `echo \\`
+ echo \
+ echo \
\ <-------- Watch this...
echo $(echo \\)
+ echo \
+ echo \
\
$ bash ./test1.sh
echo `echo \\`
echo \
++ echo
+ echo
<-------- ...and this!
echo $(echo \\)
echo \\)
echo \\
++ echo '\'
+ echo '\'
\
Mathias
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tony Baldwin
Jan 21, 2012, 3:00:02 PM1/21/12
to
./tony
--
http://www.tonybaldwin.me
all tony, all the time!
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
Jan 21, 2012, 4:10:02 PM1/21/12
to
On Sat, 21 Jan 2012 23:19:01 +0530, J. Bakshi wrote:
> On Sat, 21 Jan 2012 16:45:46 +0000 (UTC) Camaleón <noel...@gmail.com>
> wrote:
(...)
> On Sat, 21 Jan 2012 16:45:46 +0000 (UTC) Camaleón <noel...@gmail.com>
> wrote:
>> > Thanks for your suggestion. But I don't know if there is any cookie
>> > at all. I just observe through browser, If I visit the same link next
>> > time or refresh; I get a new captcha code. And the embedded captcha
>> > string also changes when open or reload the login form. So when I
>> > download the captcha, that very step also reload a new captcha. How
>> > can I know if there is any cookie responsible for that session ?
>>
>> You have to read the html code of the page... and know how to interpret
>> it (you need to know some of the basics of html and javascript
>> language) :-)
>>
>> Or you can load the page from firefox (or any other browser that can
>> display such information) right-click over it and choose "View page
>> information". If the site tries to set a cookie it will be listed under
>> "Security" tab.
>>
>>
>>
> I have very little knowledge on html and javascript. And I'm really
> thankful to you for your kind guidance. Following your tips I have seen
> there is indeed a cookie.
>
> NAME: PHPSESSID
> Content: 6cfd4a0b968778714d093d66a66b92a5
Then try to play with the samples given at wget man page for the "--post-
> thankful to you for your kind guidance. Following your tips I have seen
> there is indeed a cookie.
>
> NAME: PHPSESSID
> Content: 6cfd4a0b968778714d093d66a66b92a5
data" command.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lisi
Jan 21, 2012, 4:30:01 PM1/21/12
to
On Saturday 21 January 2012 17:15:01 Tony Baldwin wrote:
> > But he'll still have to solve the captcha to establish the session.
>
> Indeed.
> Isn't the whole point of using captcha to prevent automated access to
> stuff? (ie. require human interaction).
Quite. If J. Bakshi could program his computer to input captchas, so could
> > But he'll still have to solve the captcha to establish the session.
>
> Indeed.
> Isn't the whole point of using captcha to prevent automated access to
> stuff? (ie. require human interaction).
every villain that the captcha is meant to foil.
Though it would be nice if they made the captchas a little bit less difficult
for partially sighted humans. :-(
Lisi
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
Jan 21, 2012, 4:50:02 PM1/21/12
to
On Sat, 21 Jan 2012 12:15:01 -0500, Tony Baldwin wrote:
> On Sat, Jan 21, 2012 at 10:59:21AM -0600, John Hasler wrote:
>> Bob writes:
>> > This should enable the separate wget invocations to appear as a
>> > single session client to the remote web site.
>>
>> But he'll still have to solve the captcha to establish the session.
>
> Indeed.
> Isn't the whole point of using captcha to prevent automated access to
> stuff? (ie. require human interaction).
(...)
> On Sat, Jan 21, 2012 at 10:59:21AM -0600, John Hasler wrote:
>> Bob writes:
>> > This should enable the separate wget invocations to appear as a
>> > single session client to the remote web site.
>>
>> But he'll still have to solve the captcha to establish the session.
>
> Indeed.
> Isn't the whole point of using captcha to prevent automated access to
> stuff? (ie. require human interaction).
Captchas based on images have been "cracked" since loooong time ago ;-)
And not always for doing "bad things". For example, SpamAssassin uses OCR
techniques to "decode" spam messages which are embedded inside images.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Scott Ferguson
Jan 21, 2012, 6:40:02 PM1/21/12
to
On 22/01/12 03:59, John Hasler wrote:
> Bob writes:
>> This should enable the separate wget invocations to appear as a single
>> session client to the remote web site.
>
> But he'll still have to solve the captcha to establish the session.
In theory yes.... but only if the theory is sound (in which case it
> Bob writes:
>> This should enable the separate wget invocations to appear as a single
>> session client to the remote web site.
>
> But he'll still have to solve the captcha to establish the session.
wouldn't be a theory).
Eg. No biscuits without please (if I ask Mum nice she'll give me a biscuit)
Or... I can bypass Mum.
Randomly generated key required? There's at least two ways around
that... (how random is random?)
"There's a crack, a crack in everything. That's how the light gets in."
NOTE/Disclaimer: I think this subject is well outside what Debian-users
list is for.
Cheers
--
Iceweasel/Firefox extensions for finding answers to Debian questions:-
https://addons.mozilla.org/en-US/firefox/collections/Scott_Ferguson/debian/
NOTE: new update available for Debian Buttons
(for querying Debian Developer Package):-
https://addons.mozilla.org/en-US/firefox/addon/debian-buttons/
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages