HttpWebRequest losing cookies

2
votes

I have a client application that is communicating with an ASP.NET web service using cookie-based authentication. (the clients call a login method which sets a persistent cookie that is then re-used across requests within the logon session).

This has been working fine for some time, but I have started getting error reports from a few machines used by a new client that seem to indicate that the cookie has not been successfully roundtripped. (Login requests are all successful, but all subsequent requests fail with a 302-redirect to the logon resource)

I am using a CookieContainer which I manually attach to each HttpWebRequest I am using to ensure that the cookies are preserved across every request.

Is it possible that there is some "security" software on these machines that is intercepting/blocking the cookie transmission? (I am using SSL). If so, is there anything that can be done to tell what is getting in the way?

1
c#cookieshttpwebrequest
Are you sure you attaching the same CookieContainer instance to each HttpWebRequest? What do you mean with "I am using to ensure that the cookies are preserved across every request"? How are you ensuring that? – DxCK
could you to sniff that communication with fiddler? – Rubens Farias
yes, I am using the same container... it is working just fine on 99% of the machines connecting, there are just a handful that don't work at all. (that quote meant that I was attaching the same cookiecontainer to each web request so that the individual requests share the same set of cookies. – homeInAStar
@Rubens, I can't easily get fiddler or another tracing tool on these machines because they are offsite. I have added some additional logging to the app in hopes of isolating the issue. I have tried to reproduce using local machines and haven't been able to do so. I guess my main question was whether it was possible for "security" software to be messing with my app in this way (especially since SSL should protect the data in transit). – homeInAStar

1 Answers

0
votes

It's highly unlike that security software can even see inside your packet if you're using SSL. SSL data should be encrypted even before they get into packet form; generally they are encrypted even before using the send() to the socket. Unless you have some awesome security software that has broken SSL encryption and can look inside the packet, this shouldn't be possible.

Are the same machines failing every time? Or are some machines failing randomly at times, and others failing at other times? If it's the latter, maybe there's something going on on the server, not the clients.