0

EDIT Since debugging updates

According to the .net cookie documentation:

After you add a cookie by using the HttpResponse.Cookies collection, the cookie is immediately available in the HttpRequest.Cookies collection, even if the response has not been sent to the client.

My original observation were that my cookies appeared to be out of sync. After Receiving IUserIdentity, I would set an authentication cookie like so:

HttpContext.Current.Response
    .RemoveCookie(FormsAuthentication.FormsCookieName);  

HttpContext.Current.Request
    .RemoveCookie(FormsAuthentication.FormsCookieName);

var authCookie = FormsAuthenticationExtensions.GetPersistentAuthCookie(
                FormsAuthentication.FormsCookieName, FormsAuthentication.Encrypt(ticket), ticket.Expiration)
HttpContext.Current.Response.Cookies.Set(authCookie);

First I noticed that to values for the cookies we're not the same, after inspecting the same cookie in the watch window I noticed the value for the same cookie wasn't even the same:

enter image description here

I walked the code, and noticed that a duplicate cookie value was being set during a statement which didn't execute code. (e.g when stepping into an unrelated function the cookie now the duplicate cookie appeared in the Request and Response Cookies)

I proceeded to update all references to the cookie name in the code to help help verify what could be causing this (VM-AT-89001) => (VM-PAT-89001):

<authentication mode="Forms">
  <forms cookieless="UseUri" name="VM-PAT-89001" requireSSL="true" slidingExpiration="true" timeout="1" />
</authentication>

I cleared all existing cookies, deleted the Temporary ASP.NET Files

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Did an IISReset and Reset my computer. When walking the code again, still the OLD cookie name was being added to the request and response.

enter image description here

The configurations of the cookies are different but they have the same expiration date. e.g only 1 is HTTP Only.

NOTE I've search the entire organization code base in github and there is no reference in the code to the Old Token.

They fact that this behavior happens at different points in the code depending on which controller method I call, makes me think that this is happening on a seperate thread.

Since there is no reference to the Cookie name it makes me think IIS is modifying the cookie, but this is even more perplexing because I didn't think IIS had access to the HttpContext.Current, because I can see the cookie while still debugging and not After.

How can a cookie be added to a response, when there is no reference to the cookie name in the code, and it occurs during an No-Op statement in debugger?

EDIT I've removed all filters and modules from the application (Except for adding default json formatters), and I navigate to a page that doesn't exist, and still the old token is added to the request

How can this occur?

johnny 5
  • 19,893
  • 50
  • 121
  • 195
  • I think it would help if you could explain what your goal is here. I can't understand why you need this to work the way you have described. – howcheng Aug 28 '19 at 23:18
  • @howcheng, the way I've described is the way the microsoft documentations describes it. The underlying framework relies on the new cookie being in the request and not the expired one – johnny 5 Aug 29 '19 at 03:12
  • Are you sure that the HttpContext is the right place to set those cookies for WCF calls? I always tend to use the OperationContext for that, as shown here: https://stackoverflow.com/a/20968135/578411 but depending on where you run your code that might not be possible. – rene Aug 29 '19 at 14:42
  • @rene We set the cookies on the http context and we have a custom behavior in web-api which consumes wcf services, in our web-api side we set a header in wcf request from the HttpContext. – johnny 5 Aug 29 '19 at 14:47
  • Hmm, okay. I've not digged deep enough but there is *some* logic that literally keeps the two collections in sync but it doesn't look like it does that in a thread safe manner. Can you check what happens if you re-add the property you watch that appears out of sync? The collections are synchronized when you get actual cookiecollection. I would expect them to be in sync after you re-added that property. – rene Aug 29 '19 at 14:55
  • My thought is that in the pipeline, the code is hitting a place where authentication is required. Since you've deleted the cookie with the auth ticket, you get a new one created in its place. – howcheng Aug 29 '19 at 22:45
  • @rene, when the request comes in all the cookies are fine. When I walk the code, The cookies change at some random statement. Depending on what controller method I call, the statement changes. This makes me believe that its a threading issue. But this also doesn't make sense to me because I don't spawn any additional threads. – johnny 5 Aug 30 '19 at 00:21
  • @howcheng, yeah I've walked the full code, nothing seems to be adding it from my code, maybe its underlying in the .net-framework but its unclear how – johnny 5 Aug 30 '19 at 00:24
  • You're guaranteed to stay on the same thread just before the Response is going to be rendered to the client. The framework might pick a new thread to process the Response, or use the same thread. – rene Aug 30 '19 at 05:43

0 Answers0