Trouble using HTTP transaction sensor with 302 Redirect

Sorry about the lousy formatting - I can't get the edit page to submit properly. :(

The content for a page beyond a login can be checked with the following script: http://pastebin.com/fN32NDZq

In order to install the sensors, proceed with the following steps:

1. Run a 32 Bit PowerShell with administrative privileges on the PRTG Core Server or a remote probe (if the site is monitored by one)
2. Execute the following command: "Set-ExecutionPolicy RemoteSigned"
3. Copy the attached script to C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE\Get-Weblogin.ps1 (or whatever name you like)
4. Modify the default parameters if necessary, except for the password - leave it that way since you can't properly hand it over (at least I couldn't)
5. Create a new Sensor: EXE/Script
6. Select the script you just copied

Now, for the parameters. The script needs a URL, the ID of the username and password fields, the form ID and the string it should check on the page after the login (e.g. Logged in as Mathieu). The ID of the input fields can be easily determined by looking at the login page source. Take this example from PRTG:

<label for="loginusername">Anmeldename</label>
<input class="text" id="loginusername" name="username" type="text" value=""/>
<label for="loginpassword">Kennwort</label>
<input class="text" id="loginpassword" name="password" type="password" value=""/>

So, the IDs would be "loginusername" and "loginpassword". Now, for the form ID - open up your PowerShell and enter the following command: (Invoke-WebRequest -Uri "insert-your-url-here" -SessionVariable PRTG).Forms

This will output something like this - http://pastebin.com/k9194Lma - and you will get all the forms available. The first form would have the ID 0, the second is 1 etc.

So, the parameter field would look something like this: -URL "http://your-url.com/"
-Username "Administrator"
-Password "thepassW0rd"
-UsernameID "loginusername"
-PasswordID "loginpassword"
-CheckString "Logged in as User"
-Logout "the-logout-url"

This is what goes into the sensors parameter field. The default FormID is 0, so I left it out. Pass it if your login page has multiple forms! :) The script has it's caveats however:

• It will only work with a PowerShell that is started with -NoProfile if you want to test it outside of PRTG
• It won't work with PRTGs login page for reasons unknown :(

The sensor will automatically logout after the check. It will stay green, as long as the checkword is found. If its not found, it will go into a down state. That might happen if the site changes or the login doesn't work anymore.

Thank you so much for your response! This looks great, but I am still having some trouble with it.

The first issue I ran into (and was able to fix) was in the form of several errors that included this message:

Response not wellformed: "(Invoke-WebRequest : The response content cannot be parsed because the Internet Explorer engine is not available, or Internet Explorer's first-launch configuration is not complete. Specify the UseBasicParsing parameter and try again. At C:\Program Files (x86)\PRTG Network Monitor\custom sensors\EXE\Get-Weblogin.ps1:31 char:15 + $loginPage = (Invoke-WebRequest -Uri "$url" -SessionVariable PRTG) +

I specified the -UseBasicParsing parameter for each Invoke-WebRequest call, and these errors went away.

The second problem, which is proving to be persistent, appears to be an issue with array creation/initialization:

{{{Cannot index into a null array. At C:\Program Files (x86)\PRTG Network Monitor\custom sensors\EXE\Get-Weblogin.ps1:33 char:1 + $LoginForm = $loginPage.Forms[$formId]; + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : NullArray

Cannot index into a null array. At C:\Program Files (x86)\PRTG Network Monitor\custom sensors\EXE\Get-Weblogin.ps1:34 char:1 + $LoginForm.Fields[$usernameId] = $username; + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : NullArray

Cannot index into a null array. At C:\Program Files (x86)\PRTG Network Monitor\custom sensors\EXE\Get-Weblogin.ps1:35 char:1 + $LoginForm.Fields[$passwordId] = $password; + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : NullArray

0:Login failed or checkstring not found. Please check if the username/password combination as well as the checkstring are correct!}}}

Is it possible the array is not being initialized properly?

What's the output of (Invoke-WebRequest -Uri "insert-your-url-here" -SessionVariable PRTG).Forms

Here is the output:

PS C:\Windows\System32\WindowsPowerShell\v1.0> (Invoke-WebRequest -Uri "https://my.uindy.edu" -SessionVariable PRTG).Forms

Id                            Method                        Action                        Fields
--                            ------                        ------                        ------
fm1                           post                          /cas/login;jsessionid=5278... {[username, ], [password, ...

Hm, looks okay - can you create a test account for me? I won't publish the post so only I can see the credentials :)

I wish I could create an account for you but unfortunately that's not something we can do due to red tape issues. Sorry. We could do a screensharing session to work together if that would work, or I'm open to other suggestions.

Did you actually try what the error message suggested? I.e. launching IE and completing its setup once? :)

I did. :) IE had been used on this server before, so launching it to check just yielded the Enhanced Security Configuration Disabled page and I can browse to websites as expected. The message about IE setup seemed only to pertain to the first Response not wellformed error which went away after I added the -UseBasicParsing parameter to the Invoke-WebRequest calls. The NullArray error is still triggering.

Really old thread, but I'm coming up against a similar issue. The parameters for the webpage are:

[string]$usernameId = "UserId", [string]$passwordId = "Password",

But when I run the PS script (with the -noprofile option) with the parameters hardcoded, I get the following errors:

Cannot index into a null array. At D:\Test.ps1:34 char:1 + $LoginForm.Fields[$usernameId] = $username; + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : NullArray

Cannot index into a null array. At D:\Test.ps1:35 char:1 + $LoginForm.Fields[$passwordId] = $password; + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : NullArray

failed or checkstring not found. Please check if the username/password combination as well as the checkstring are correct!

I've double checked the source of the webpage to make sure I have the fields correct - just for completeness, here they are:

<INPUT id="UserId" autocomplete="off" onfocus="this.select()" value="" onchange="try { rememberCredendials.checked = false } catch( e ) {}"> <A id="CcowLink" tabindex="-1"></A>

<INPUT type="password" id="Password" autocomplete="off" onfocus="this.select()">

I'm really keen to get the monitoring script to work, but need it to be able to log into the website to make sure it's all working correctly.

Has anyone got any ideas as to what might be causing this?

Thanks in advance,

David

Sorry, update to the previous post. I managed to get the script to run OK in Powershell; turns out it was returning a webpage saying it was an Unsupported Browser (!) - so added

[string]$Useragent = "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)"

and it runs fine. The strange thing, is instead of checking the page returned following the submission of the login & password for the checkstring, it is searching the initial $url page.

Why would it be doing this??

Thanks,

David

Because it simply checks the content of the original URL, not the redirect location.
Maybe this helps? You'll need to modify the script accordingly though.

Kind regards,
Stephan Linke, Tech Support Team