How do you get a seperate client process to talk to ASP.NET App

[Greg Liles]

I've logged into an ASP.Net server through my browser. My browser runs
an activex control. The activex control starts an activex EXE that needs
to communicate to the server.

The problem is when the activex EXE tries to talk to the server, the
server redirects the request to the log in page. I'm using basic ASP.NET
authentication on the server.

The question is, how do you get a client process to imposter as the
original browser process so that the server thinks it is logged in? The
client software needs to run outside of .NET.

Thanks,

-Greg Liles

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[John Saunders]

"Greg Liles" <gr********@neogenesys.us> wrote in message
news:uO*************@TK2MSFTNGP12.phx.gbl...

I've logged into an ASP.Net server through my browser. My browser runs
an activex control. The activex control starts an activex EXE that needs
to communicate to the server.

The problem is when the activex EXE tries to talk to the server, the
server redirects the request to the log in page. I'm using basic ASP.NET
authentication on the server.

The question is, how do you get a client process to imposter as the
original browser process so that the server thinks it is logged in? The
client software needs to run outside of .NET.

If you're using Forms Authentication, then your client will need to send the
same Forms Authentication cookie as the browser would.
--
John Saunders
Internet Engineer
jo***********@surfcontrol.com

[Greg Liles]

OK, I tried that. At least I think I tried that.

What I did was add a header sent back to the server that has my
authentication cookie information. The header looks like this:

Cookie: ASP.NET_SessionId=51w0nt55lompdn55sxzf4t45;
login=7BA0D2CD1686AAA9E00E393B709628808572D38131D3 4132838BB2888190B757B3
04451E9C5EFC99EB7A15159F90E02AB16C6C50FD5D6DA54C28 E47A712DBA6BD8A2DF89E2
828150

I verified that the header was indeeed sent back using an HTTP sniffer.

However, the server still denies the new process access. I still get the
login screen.

Am I doing something wrong in sending the cookie?

-Greg Liles
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[John Saunders]

"Greg Liles" <gr********@neogenesys.us> wrote in message
news:uy*************@TK2MSFTNGP12.phx.gbl...

OK, I tried that. At least I think I tried that.

What I did was add a header sent back to the server that has my
authentication cookie information. The header looks like this:

Cookie: ASP.NET_SessionId=51w0nt55lompdn55sxzf4t45;
login=7BA0D2CD1686AAA9E00E393B709628808572D38131D3 4132838BB2888190B757B3
04451E9C5EFC99EB7A15159F90E02AB16C6C50FD5D6DA54C28 E47A712DBA6BD8A2DF89E2
828150

I verified that the header was indeeed sent back using an HTTP sniffer.

However, the server still denies the new process access. I still get the
login screen.

Am I doing something wrong in sending the cookie?

Not as far as I can see. I'd add some code to the login page to display the
Cookies collection in order to confirm which cookies get there. And I'd add
a "foo=bar" cookie just to test.

I don't know whether it will be an issue that you're trying to use the same
session ID when you're using a different connection.

I also don't know whether the encryption of the Forms Authentication cookie
is dependant on the session.
--
John Saunders
Internet Engineer
jo***********@surfcontrol.com