2

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?

homeInAStar
  • 226
  • 2
  • 5
  • 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 Jan 23 '10 at 21:30
  • could you to sniff that communication with fiddler? – Rubens Farias Jan 23 '10 at 21:32
  • 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 Jan 23 '10 at 21:33
  • @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 Jan 23 '10 at 21:36

1 Answers1

0

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.

atanamir
  • 4,833
  • 3
  • 24
  • 20
  • The same set of 3 machines fail all the time. When the users from those machines switch to other machines, everything seems to work fine for them. I have deployed some updated diagnostics, hopefully I will be able to capture more information from these machines. – homeInAStar Jan 24 '10 at 16:07
  • You can enable tracelogging for your app. See this: http://ferozedaud.blogspot.com/2009/08/tracing-with-systemnet.html. Then have a look at the logfile to see why the cookie is not being sent. – feroze Jan 25 '10 at 02:32
  • Also, is it possible that there is a load balancer between the client and servers? So, if maching M1 is setting the cookie on the response, but if the subsequent request is going to machine M2, then M2 will obviously have no idea what to do with that cookie, and might discard it. – feroze Jan 25 '10 at 19:49