security page block issue

[Rolf Kalbermatter]

QUOTE (tcplomp @ Apr 2 2008, 02:22 PM)

This can be done by loading the actual connection VI via VI server.

If you do a dynamic load and close it all info (inside LabVIEW) about the connection is lost.

Yes but it's a clutch and the symptoms clearly point to a connection refnum not explicitedly closed. Unloading the VI or LabVIEW altogether will close that connection, but closing it yourself explicitedly is definitly the right course of action.

Rolf Kalbermatter

[psiam]

I noticed you are not closing the data socket. I don't know if this will help or not, but you could try something like this...

It doesn't work,it still show the same problem (need user and password),pls see picture below.

Do you have any suggestion,pls feel free let me know.

[psiam]

QUOTE (tcplomp @ Apr 3 2008, 01:22 AM)

This can be done by loading the actual connection VI via VI server. If you do a dynamic load and close it all info (inside LabVIEW) about the connection is lost. That should do th the job. Ton

It doesn't work for VI server,do you have any suggestion,pls feel free let me know.

[LAVA 1.0 Content]

QUOTE (psiam @ Apr 3 2008, 05:27 AM)

It doesn't work for VI server,do you have any suggestion,pls feel free let me know.

The following is a wild guess.

Try checking the "automatically close VISA" to see if that helps with the VI Server method.

Done guessing!

Ben

[psiam]

QUOTE (neB @ Apr 4 2008, 12:02 AM)

The following is a wild guess. Try checking the "automatically close VISA" to see if that helps with the VI Server method. Done guessing! Ben

Yes,we have automatically close VISA ,but still not working,pls see in picture.

[TobyD]

QUOTE (psiam @ Apr 3 2008, 06:14 PM)

Yes,we have automatically close VISA ,but still not working,pls see in picture.

This is a long shot, but could it be related to any of the windows security settings? Maybe your OS is blocking access somehow.

[Rolf Kalbermatter]

QUOTE (TobyD @ Apr 4 2008, 02:26 PM)

This is a long shot, but could it be related to any of the windows security settings? Maybe your OS is blocking access somehow.

It is a long shot :-). I think the problem might be more related to the fact that he is using LV 7.1 or lower according to his list and that DS had some issues about closing sessions properly somehow in earlier days. My memory is all fuzzy about this and it could also have been something in the DS connection of front panel controls and not sure if it was LabVIEW 6.x, 7.0 or 7.1 but there were definitly some issues. However that's so long ago I couldn't remember the details anymore, especially since I never used DS myself.

Maybe also check the error cluster too. It could be that DS Read returns an error despite returning data and that DS Close does not close then which would be a bug, but it has happened in the past that some Close functions didn't execute if the error input was set to indicate an error.

Rolf Kalbermatter

[orko]

By the look of the source you provided, it looks like there is a cookie being stored when you log on successfully (you can see the error javascript source setting this cookie's string to "LOGIN_LEVEL=0; path = / " on failure ).

This might explain why the first attempt succeeds and the second one fails -- if there is a session cookie set up to store some sort of connection/session ID and it doesn't match when sent to the second unit you are testing.

I'm unclear on how LabVIEW (datasocket or VI server) stores cookie related information in it's session cache. But if my instincts are correct in Windows, I would assume it uses the same mechanisms that Internet Explorer uses. That is if LV7.x supported session cookies at all...

To test this, before running the second unit's test try clearing out Internet Explorer's cache and cookie history. In fact it may be a good idea to clear them out first before running the first test so you can see if there is a file being stored in your cookies for the IP you are using. If there isn't a persistent cookie file being stored (and I'm thinking there probably isn't), then this is a session based cookie and you won't be able to just clear it out every time manually (because the only way I could think to clear a session cookie would be to close LabVIEW like you are doing).

Another option is to just re-request the page on this failure? Since the error page is "logging you out" via Javascript by clearing this cookie's content, wouldn't a simple retry work just like the login to the first unit?

And yet another option is to disable cookies altogether in the security settings of your OS and see if there is a failback method that the unit uses for login...

I hate cookies...

[Rolf Kalbermatter]

QUOTE (orko @ Apr 4 2008, 03:34 PM)

I hate cookies...

No, no!!! There are so many delicious cookies!

Rolf Kalbermatter

[psiam]

QUOTE (rolfk @ Apr 5 2008, 02:39 AM)

It is a long shot :-). I think the problem might be more related to the fact that he is using LV 7.1 or lower according to his list and that DS had some issues about closing sessions properly somehow in earlier days. My memory is all fuzzy about this and it could also have been something in the DS connection of front panel controls and not sure if it was LabVIEW 6.x, 7.0 or 7.1 but there were definitly some issues. However that's so long ago I couldn't remember the details anymore, especially since I never used DS myself. Maybe also check the error cluster too. It could be that DS Read returns an error despite returning data and that DS Close does not close then which would be a bug, but it has happened in the past that some Close functions didn't execute if the error input was set to indicate an error. Rolf Kalbermatter

I tried that with LabView8.0,it still not working.

[orko]

Piecing together the tidbits of HTML & JavaScript that you've provided in your screenshots, this URL should be the one that is requested when you submit the form (don't put the "ADMIN:ADMIN@" at the front of this):

http://192.168.40.125:20080/EMSRequest/LoginConfirm?Login_id=Login&user=ADMIN&ConfirmPwd=ADMIN

Temporarily remove the wire going into the DS Open Connection and DS Read and wire the above URL instead as a constant to see if it will work. And no, you shouldn't need to put the [text] at the end, since datasockets use text as default. Check to verify the correct IP and port is in the URL first, of course.

If using this URL still doesn't work, you've more than likely got a session cookie problem (as described above) or something quirky going on with the dynamic content being provided from the unit. An easy way to check this would be to use something other than LV and see if it works... like Curl or Wget

[psiam]

QUOTE (orko @ Apr 8 2008, 09:05 PM)

Piecing together the tidbits of HTML & JavaScript that you've provided in your screenshots, this URL should be the one that is requested when you submit the form (don't put the "ADMIN:ADMIN@" at the front of this):

http://192.168.40.125:20080/EMSRequest/LoginConfirm?Login_id=Login&user=ADMIN&ConfirmPwd=ADMIN

Temporarily remove the wire going into the DS Open Connection and DS Read and wire the above URL instead as a constant to see if it will work. And no, you shouldn't need to put the [text] at the end, since datasockets use text as default. Check to verify the correct IP and port is in the URL first, of course. If using this URL still doesn't work, you've more than likely got a session cookie problem (as described above) or something quirky going on with the dynamic content being provided from the unit. An easy way to check this would be to use something other than LV and see if it works... like Curl or Wget

This is result for Curl solution,still not working.

[orko]

Have you tried this from the command line?:

C:\curl -i http://192.168.40.125:20080/EMSRequest/LoginConfirm?Login_id=Login&user=ADMIN&ConfirmPwd=ADMIN

[psiam]

QUOTE (orko @ Apr 18 2008, 09:09 PM)

Have you tried this from the command line?:

C:\curl -i http://192.168.40.125:20080/EMSRequest/LoginConfirm?Login_id=Login&user=ADMIN&ConfirmPwd=ADMIN

still don't work for both of C:\curl -i and C:\curl -l,for more info see in attach file.

[orko]

QUOTE (psiam @ Apr 24 2008, 03:28 AM)

still don't work for both of C:\curl -i and C:\curl -l,for more info see in attach file.

Hmm. Can't see the code that produced the FP you showed us. But if that doesn't work you may be working against some sort of cookie issue as noted.

Since I'm assuming all of this works when requested by a browser, I wonder if a straight-up Internet Explorer embedded ActiveX control on your front panel may be another solution? I'm not sure (never tried it) but wouldn't you have access to the source HTML if you requested a page in the ActiveX container? I guess for that matter you wouldn't even need to show the control, it could be hidden and doing operations in the background.

Has anyone else here had any experience in doing it that way? Basically having IE do all the work by having it request pages for you (you would have to POST the login info from IE on the first call of course) and grabbing the HTML source to parse out the test results?

Sorry I can't be of any more help than that.