Re: [Nagios-users] Using nagios check_httpfor webbasedauthentication
Hi Peter, To the extent followed with some googling, there is no help on this. Dropping it off for now. Thanks Venu -Original Message- From: peter.ri...@web.de [mailto:peter.ri...@web.de] Sent: Sunday, January 25, 2009 4:02 AM To: Venugopal S Cc: nagios-users@lists.sourceforge.net Subject: Re: [Nagios-users] Using nagios check_httpfor webbasedauthentication Hi Venu, do you know 'check_website'. I use it for monitoring a handful websites. It's able to follow applications even with dynamically generated URLs. As far as I remember (I dont need it) it follows redirects. It' worth a look. Regards, Peter Venugopal S schrieb: > Hi Marc, > > Will try this out on Tuesday. Thanks for your immense help. > > Happy weekend for all of you there. > > > -Original Message- > From: Marc Powell [mailto:m...@ena.com] > Sent: Friday, January 23, 2009 7:17 PM > To: nagios-users@lists.sourceforge.net > Subject: Re: [Nagios-users] Using nagios check_httpfor > webbasedauthentication > > > On Jan 22, 2009, at 11:59 PM, Venugopal S wrote: > >> Hi Joerge, >> >> As you said "welcome venu" is not in the response in spite of giving >> valid credentials. That is why I am wondering ! >> Even I gave the -v switch and found in the HTML response that "welcome >> venu" is not found. And the response HTML is the same as signin.do. It >> must have thrown me the login success page isn't it ? > >> ./check_http -I 199.107.237.196 -H ww12.1800flowers.com -u / >> signin.do -p 80 -P "email=svenugop...@gmail.com&password=podhum" -s >> "welcome venu" > > > > Hi Venu, > > I created an account to test and see that I gave you some incorrect > information. Looking at the form HTML, the URL that the form > information is actually posted to is /signinaction.do, not /signin.do > so that will need to change that in the command definition. > > Now with the correct URL and successful login, I see that the success > 'page' returned is just a 302 redirect that bounces you to > > Location: https://ww12.1800flowers.com/customerwelcome.do?cmReg=L > > Unfortunately we come to a stopping point here. check_http will need > to follow that redirect if it's going to see the text you're expecting > to see on the final page and it can do that with --onredirect=follow. > The problem is that the coding of the final landing page appears to > absolutely require the presence of a login cookie to know that you're > logged in. check_http does not pass cookies as part of a redirect (but > can be programmed to pass static cookies using the -k switch). The > cookies that are being passed to us appear to be temporary session > cookies anyway so I'm not sure how useful it would be to create > another check for the customerwelcome.do page. > > What I ended up with is -- > > ./check_http -I 199.107.237.196 -H ww12.1800flowers.com -u / > signinaction.do -p 80 -P "email=myaddress&password=mypass" -e 302 -r > html --invert-regex > > This will ensure that we see the 302 redirect returned by a successful > login and that we do not see the word 'html' in a web page instead of > the 302 redirect (meaning the login failed). Essentially, you'll know > that the login worked, but not that the customerwelcome.do page was > actually displayed. That may be enough for your needs. > > -- > Marc > > > > > > > > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > ___ > Nagios-users mailing list > Nagios-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagios-users > ::: Please include Nagios version, plugin version (-v) and OS when > reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > > This email message and its attachments may contain CONFIDENTIAL AND PRIVILEGED INFORMATION intended for the sole use of the addressee(s). If you have received it in error, please contact the sender by return email, notify your system manager and destroy the original message and any copies thereof. Any review, use, disclosure or distribution is unlawful. Please check this email and any attachments for the presence of viruses. The Company accepts no liability for any damage caused by any virus transmitted by this email. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. > The Company reserves the right to
Re: [Nagios-users] Using nagios check_httpfor webbasedauthentication
Hi Venu, do you know 'check_website'. I use it for monitoring a handful websites. It's able to follow applications even with dynamically generated URLs. As far as I remember (I dont need it) it follows redirects. It' worth a look. Regards, Peter Venugopal S schrieb: > Hi Marc, > > Will try this out on Tuesday. Thanks for your immense help. > > Happy weekend for all of you there. > > > -Original Message- > From: Marc Powell [mailto:m...@ena.com] > Sent: Friday, January 23, 2009 7:17 PM > To: nagios-users@lists.sourceforge.net > Subject: Re: [Nagios-users] Using nagios check_httpfor > webbasedauthentication > > > On Jan 22, 2009, at 11:59 PM, Venugopal S wrote: > >> Hi Joerge, >> >> As you said "welcome venu" is not in the response in spite of giving >> valid credentials. That is why I am wondering ! >> Even I gave the -v switch and found in the HTML response that "welcome >> venu" is not found. And the response HTML is the same as signin.do. It >> must have thrown me the login success page isn't it ? > >> ./check_http -I 199.107.237.196 -H ww12.1800flowers.com -u / >> signin.do -p 80 -P "email=svenugop...@gmail.com&password=podhum" -s >> "welcome venu" > > > > Hi Venu, > > I created an account to test and see that I gave you some incorrect > information. Looking at the form HTML, the URL that the form > information is actually posted to is /signinaction.do, not /signin.do > so that will need to change that in the command definition. > > Now with the correct URL and successful login, I see that the success > 'page' returned is just a 302 redirect that bounces you to > > Location: https://ww12.1800flowers.com/customerwelcome.do?cmReg=L > > Unfortunately we come to a stopping point here. check_http will need > to follow that redirect if it's going to see the text you're expecting > to see on the final page and it can do that with --onredirect=follow. > The problem is that the coding of the final landing page appears to > absolutely require the presence of a login cookie to know that you're > logged in. check_http does not pass cookies as part of a redirect (but > can be programmed to pass static cookies using the -k switch). The > cookies that are being passed to us appear to be temporary session > cookies anyway so I'm not sure how useful it would be to create > another check for the customerwelcome.do page. > > What I ended up with is -- > > ./check_http -I 199.107.237.196 -H ww12.1800flowers.com -u / > signinaction.do -p 80 -P "email=myaddress&password=mypass" -e 302 -r > html --invert-regex > > This will ensure that we see the 302 redirect returned by a successful > login and that we do not see the word 'html' in a web page instead of > the 302 redirect (meaning the login failed). Essentially, you'll know > that the login worked, but not that the customerwelcome.do page was > actually displayed. That may be enough for your needs. > > -- > Marc > > > > > > > > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > ___ > Nagios-users mailing list > Nagios-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagios-users > ::: Please include Nagios version, plugin version (-v) and OS when > reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > > This email message and its attachments may contain CONFIDENTIAL AND > PRIVILEGED INFORMATION intended for the sole use of the addressee(s). If you > have received it in error, please contact the sender by return email, notify > your system manager and destroy the original message and any copies thereof. > Any review, use, disclosure or distribution is unlawful. Please check this > email and any attachments for the presence of viruses. The Company accepts no > liability for any damage caused by any virus transmitted by this email. The > views or opinions presented in this e-mail are solely those of the author and > do not necessarily represent those of the company. > The Company reserves the right to monitor, review and store the content of > all messages sent to or from this e-mail address. > > www.aztecsoft.com > > -- > This SF.
Re: [Nagios-users] Using nagios check_httpfor webbasedauthentication
Hi Marc, Will try this out on Tuesday. Thanks for your immense help. Happy weekend for all of you there. -Original Message- From: Marc Powell [mailto:m...@ena.com] Sent: Friday, January 23, 2009 7:17 PM To: nagios-users@lists.sourceforge.net Subject: Re: [Nagios-users] Using nagios check_httpfor webbasedauthentication On Jan 22, 2009, at 11:59 PM, Venugopal S wrote: > > Hi Joerge, > > As you said "welcome venu" is not in the response in spite of giving > valid credentials. That is why I am wondering ! > Even I gave the -v switch and found in the HTML response that "welcome > venu" is not found. And the response HTML is the same as signin.do. It > must have thrown me the login success page isn't it ? > ./check_http -I 199.107.237.196 -H ww12.1800flowers.com -u / > signin.do -p 80 -P "email=svenugop...@gmail.com&password=podhum" -s > "welcome venu" Hi Venu, I created an account to test and see that I gave you some incorrect information. Looking at the form HTML, the URL that the form information is actually posted to is /signinaction.do, not /signin.do so that will need to change that in the command definition. Now with the correct URL and successful login, I see that the success 'page' returned is just a 302 redirect that bounces you to Location: https://ww12.1800flowers.com/customerwelcome.do?cmReg=L Unfortunately we come to a stopping point here. check_http will need to follow that redirect if it's going to see the text you're expecting to see on the final page and it can do that with --onredirect=follow. The problem is that the coding of the final landing page appears to absolutely require the presence of a login cookie to know that you're logged in. check_http does not pass cookies as part of a redirect (but can be programmed to pass static cookies using the -k switch). The cookies that are being passed to us appear to be temporary session cookies anyway so I'm not sure how useful it would be to create another check for the customerwelcome.do page. What I ended up with is -- ./check_http -I 199.107.237.196 -H ww12.1800flowers.com -u / signinaction.do -p 80 -P "email=myaddress&password=mypass" -e 302 -r html --invert-regex This will ensure that we see the 302 redirect returned by a successful login and that we do not see the word 'html' in a web page instead of the 302 redirect (meaning the login failed). Essentially, you'll know that the login worked, but not that the customerwelcome.do page was actually displayed. That may be enough for your needs. -- Marc -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null This email message and its attachments may contain CONFIDENTIAL AND PRIVILEGED INFORMATION intended for the sole use of the addressee(s). If you have received it in error, please contact the sender by return email, notify your system manager and destroy the original message and any copies thereof. Any review, use, disclosure or distribution is unlawful. Please check this email and any attachments for the presence of viruses. The Company accepts no liability for any damage caused by any virus transmitted by this email. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The Company reserves the right to monitor, review and store the content of all messages sent to or from this e-mail address. www.aztecsoft.com -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Using nagios check_httpfor webbasedauthentication
On Jan 22, 2009, at 11:59 PM, Venugopal S wrote: > > Hi Joerge, > > As you said "welcome venu" is not in the response in spite of giving > valid credentials. That is why I am wondering ! > Even I gave the -v switch and found in the HTML response that "welcome > venu" is not found. And the response HTML is the same as signin.do. It > must have thrown me the login success page isn't it ? > ./check_http -I 199.107.237.196 -H ww12.1800flowers.com -u / > signin.do -p 80 -P "email=svenugop...@gmail.com&password=podhum" -s > "welcome venu" Hi Venu, I created an account to test and see that I gave you some incorrect information. Looking at the form HTML, the URL that the form information is actually posted to is /signinaction.do, not /signin.do so that will need to change that in the command definition. Now with the correct URL and successful login, I see that the success 'page' returned is just a 302 redirect that bounces you to Location: https://ww12.1800flowers.com/customerwelcome.do?cmReg=L Unfortunately we come to a stopping point here. check_http will need to follow that redirect if it's going to see the text you're expecting to see on the final page and it can do that with --onredirect=follow. The problem is that the coding of the final landing page appears to absolutely require the presence of a login cookie to know that you're logged in. check_http does not pass cookies as part of a redirect (but can be programmed to pass static cookies using the -k switch). The cookies that are being passed to us appear to be temporary session cookies anyway so I'm not sure how useful it would be to create another check for the customerwelcome.do page. What I ended up with is -- ./check_http -I 199.107.237.196 -H ww12.1800flowers.com -u / signinaction.do -p 80 -P "email=myaddress&password=mypass" -e 302 -r html --invert-regex This will ensure that we see the 302 redirect returned by a successful login and that we do not see the word 'html' in a web page instead of the 302 redirect (meaning the login failed). Essentially, you'll know that the login worked, but not that the customerwelcome.do page was actually displayed. That may be enough for your needs. -- Marc -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Using nagios check_httpfor webbasedauthentication
Actually, the response HTML usually ISN'T a login success page. Most of
the time, with form-based login, the user name and password will be
submitted to the same URL (in your case, signin.do). The Web server will
then return a page (typically, completely empty) with a status code of
302 (instead of the normal 200) and another URL in one of the headers. A
Web browser will interpret the 302 as "redirect, please go to this new
URL instead". So when you click on the "Logon" button, the browser will
actually do not one but two (or sometimes even three or more) HTTP
requests. Only the last one would contain the "welcome venu" text.
I'm not sure if check_http is smart enough to follow redirects; my guess
is that it is not; it's designed to be very simple. You may have to
either rely on status code 302 (which will also happen when login
failed), or you will have to find (or write your own) a plugin that will
follow redirects.
Venugopal S wrote:
> Hi Joerge,
>
> As you said "welcome venu" is not in the response in spite of giving
> valid credentials. That is why I am wondering !
> Even I gave the -v switch and found in the HTML response that "welcome
> venu" is not found. And the response HTML is the same as signin.do. It
> must have thrown me the login success page isn't it ?
>
> Venu
>
> -Original Message-
> From: Joerg Linge [mailto:pitchf...@ederdrom.de]
> Sent: Friday, January 23, 2009 11:20 AM
> Cc: nagios-users@lists.sourceforge.net
> Subject: Re: [Nagios-users] Using nagios check_httpfor
> webbasedauthentication
>
> Venugopal S schrieb:
>
>> Hi Marc,
>>
>>
>>
>> * This is my command in commands.cfg : *
>>
>>
>>
>> / define command{ /
>>
>> / command_namecheck_http /
>>
>> / command_line$USER1$/check_http -I $HOSTADDRESS$
>> /
>>
>> / } /
>>
>>
>>
>> I executed the following command :
>>
>>
>>
>> ./check_http -I 199.107.237.196 -H ww12.1800flowers.com -u /signin.do
>>
>
>
>> -p 80 -P "email= svenugop...@gmail.com&password=podhum" -s "welcome
>>
> venu"
>
>>
>> and it threw
>>
>>
>>
>> HTTP CRITICAL - string not found|time=0.080070s;;;0.00
>>
> size=38300B;;;0
>
>>
>> Any idea why ?
>>
>
> Add -v to you test a analyze te response. There is no string "welcome
> venu" in the response.
>
>
>
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> ___
> Nagios-users mailing list
> Nagios-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when
> reporting any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>
> This email message and its attachments may contain CONFIDENTIAL AND
> PRIVILEGED INFORMATION intended for the sole use of the addressee(s). If you
> have received it in error, please contact the sender by return email, notify
> your system manager and destroy the original message and any copies thereof.
> Any review, use, disclosure or distribution is unlawful. Please check this
> email and any attachments for the presence of viruses. The Company accepts no
> liability for any damage caused by any virus transmitted by this email. The
> views or opinions presented in this e-mail are solely those of the author and
> do not necessarily represent those of the company.
> The Company reserves the right to monitor, review and store the content of
> all messages sent to or from this e-mail address.
>
> www.aztecsoft.com
>
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> ___
> Nagios-users mailing list
> Nagios-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when reporting
> any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>
--
Kevin Keane
Owner
The NetTech
Find the Uncommon: Expert Solutions for a Netw
Re: [Nagios-users] Using nagios check_httpfor webbasedauthentication
Hi Joerge,
As you said "welcome venu" is not in the response in spite of giving
valid credentials. That is why I am wondering !
Even I gave the -v switch and found in the HTML response that "welcome
venu" is not found. And the response HTML is the same as signin.do. It
must have thrown me the login success page isn't it ?
Venu
-Original Message-
From: Joerg Linge [mailto:pitchf...@ederdrom.de]
Sent: Friday, January 23, 2009 11:20 AM
Cc: nagios-users@lists.sourceforge.net
Subject: Re: [Nagios-users] Using nagios check_httpfor
webbasedauthentication
Venugopal S schrieb:
>
>
> Hi Marc,
>
>
>
> * This is my command in commands.cfg : *
>
>
>
> / define command{ /
>
> / command_namecheck_http /
>
> / command_line$USER1$/check_http -I $HOSTADDRESS$
> /
>
> / } /
>
>
>
> I executed the following command :
>
>
>
> ./check_http -I 199.107.237.196 -H ww12.1800flowers.com -u /signin.do
> -p 80 -P "email= svenugop...@gmail.com&password=podhum" -s "welcome
venu"
>
>
>
> and it threw
>
>
>
> HTTP CRITICAL - string not found|time=0.080070s;;;0.00
size=38300B;;;0
>
>
>
> Any idea why ?
Add -v to you test a analyze te response. There is no string "welcome
venu" in the response.
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when
reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
This email message and its attachments may contain CONFIDENTIAL AND PRIVILEGED
INFORMATION intended for the sole use of the addressee(s). If you have received
it in error, please contact the sender by return email, notify your system
manager and destroy the original message and any copies thereof. Any review,
use, disclosure or distribution is unlawful. Please check this email and any
attachments for the presence of viruses. The Company accepts no liability for
any damage caused by any virus transmitted by this email. The views or opinions
presented in this e-mail are solely those of the author and do not necessarily
represent those of the company.
The Company reserves the right to monitor, review and store the content of all
messages sent to or from this e-mail address.
www.aztecsoft.com
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
