Error occurred during a cryptographic operation. about cookietempdata HOT 23 CLOSED

If you have exact repo steps, that would be appreciated. Any any event, I'll check into it this evening.

from cookietempdata.

Working on it, doing my best to break our app again :)

from cookietempdata.

Also, which version are you using? If it's prior to Jan 08, 2013, then there was a bug where you set a temp data value on the same request as a login request this would happen. IOW, on an anonymous request you write to TempData, and on that request you log the user in and then the next request the user would be authenticated and that's when you'd get this exception.

from cookietempdata.

It was just the latest from Nuget - 1.2.0.

On 26 February 2013 23:13, Brock Allen [email protected] wrote:

Also, which version are you using? If it's prior to Jan 08, 2013, then
there was a bug where you set a temp data value on the same request as a
login request this would happen. IOW, on an anonymous request you write to
TempData, and on that request you log the user in and then the next request
the user would be authenticated and that's when you'd get this exception.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-14146069
.

Ben Foster

planetcloud
Rose Cottage, The Lane
Cotham
Nottinghamshire
NG23 5JT

www.planetcloud.co.uk

**
fabrik.
Our portfolio and blogging platform for creatives
[email protected]
www.getfabrik.com

from cookietempdata.

Ok, so you're using the latest. I guess I'd want to know if you can repro when one server issues the temp data cookie and the other one is the one trying to read the cookie. Right now that's my best guess.

Also, azure or your own servers?

from cookietempdata.

Azure Virtual Machines - using the Azure Load Balancer.

Looking at our error logs in 30 minutes this happened 8 days times for a
single user - what's interesting was that the exception was thrown on the
same server each time.

On 26 February 2013 23:27, Brock Allen [email protected] wrote:

Ok, so you're using the latest. I guess I'd want to know if you can repro
when one server issues the temp data cookie and the other one is the one
trying to read the cookie. Right now that's my best guess.

Also, azure or your own servers?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-14146671
.

Ben Foster

planetcloud
Rose Cottage, The Lane
Cotham
Nottinghamshire
NG23 5JT

www.planetcloud.co.uk

**
fabrik.
Our portfolio and blogging platform for creatives
[email protected]
www.getfabrik.com

from cookietempdata.

Other thoughts:

Is the cookie too large and the user is using safari and thus the cookie is getting truncated?

Does the user have multiple tabs open?

from cookietempdata.

Hi Brock,

Checked error logs this morning and several instances of this exception - this time all on the other server so I don't think this is server specific.

Some more information:

This is happening in Chrome and Safari mostly on Macs:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17

It's possible multiple tabs were open although awaiting confirmation of that.

I can't think that the cookie is too large. We only use it to display a message to the user (the Alert object below) when doing PRG. After the user POSTs their changes we redirect back to the same page:

    [HttpPost]
    public async Task<ActionResult> Customize(int id, UpdateThemeConfigurationCommand command)
    {
        await customizationClient.UpdateThemeConfigurationAsync(Customer.CurrentSite, id, command);
        return RedirectToAction("customize", new { id = id })
            .AndAlert(AlertType.Success, "Success!", "Your customizations were applied successfully.");
    }

It is the GET request where the exception is thrown (when we attempt to read TempData to see if there is a message to be displayed).

from cookietempdata.

This happened to me today on Windows with Chrome. The worst thing about it is that once it happens (and you have the "problem" cookie on your machine) you can't browse the site again until your clear your cookies. This is obviously not good for our customers. At this stage I think I may have to just use the normal Session State based provider (using MSSQL) as we're due to launch on Monday and I'm getting nowhere fast with this.

What I can then do is set up a test application that uses the Cookie provider that is hosted in the same web farm as I think it is the web farm scenario that is causing this issue (I've not once experienced it locally).

from cookietempdata.

My guess is that the cookie is getting truncated.

from cookietempdata.

The other question -- you're using the SAM for authentication?

from cookietempdata.

Yes we are. Do you think this is related?

from cookietempdata.

I think it's cookie size. With any number of claims, the SAM can easily spit out 2K worth of cookie data, and with the CookieTempData that might be large as well. Safari is notorious for truncating cookies when the host issues more than 4K of data across all cookies (not just a single cookie).

So if this really is the issue, then we can do a few things:

1. You can cache the claims on the server: http://brockallen.com/2013/02/21/server-side-session-token-caching-in-wif-and-thinktecture-identitymodel/

and/or:

2. we can add an option to the CookieTempData to use JSON serialization (which results in smaller cookies). It used to do this, but then someone asked for the BinarySerializer because they wanted object graphs in temp data (for some reason). Anyway, this would give you a flag to improve the situation, but it's not perfect.

from cookietempdata.

Hi Brock,

It does sound like truncation may be the issue but if that's the case I should be able to replicate right?

I've tried sticking a few objects into TempData to increase the overall size (note that before it was just under 3K) but even at 5K I can't seem to re-produce the exception! Lots of hair pulling doesn't help :)

from cookietempdata.

I'm also having this issue on Macs, iPads, and PCs on Chrome and Safari (maybe other browsers too but I haven't heard of that). I have the latest from NuGet.

My users have reported it after the session has been idle for a long time and then they try to go back to the same tab or open a new tab to do something. So yes, multiple tabs. We automatically log them out after 12 minutes however, they are telling me that it happens after they've been away about an hour or more. And I've seen it under those circumstances as well. Could it be a timing issue?

One more thing I've noticed is that I either have to clear my cookies (as mentioned above) or fully close my browser to be able to continue.

Also, I'm using AppHarbor.

from cookietempdata.

@monicabirdsong are you using the Session Authentication Module?

@brockallen after adding the machine key protection for SAM session tokens we've not experienced this issue, so it would appear this was the root cause.

from cookietempdata.

@benfoster - no, at least not intentionally.I'm using SimpleMembership with MVC4. The only thing that might be odd there is that I create a custom IPrincipal in my Global.asax Application_PostAuthenticateRequest and set it to the HttpContext.Current.User

It sounds like you found a solution - congrats!

from cookietempdata.

Ok, so it sounds like people are frequently getting pages with temp data and then the user gets logged out. Bad timing, but still it's happening. So perhaps we should suppress these exceptions when we have a failure to validate. It's less intrusive for the users, but I'd like to have a way to report the exception if the app cares.

from cookietempdata.

Ok, I've made some changes. When we try to read the cookie that was issued to a logged in user, but the user is no longer logged in we act as if there's no cookie. It's the best i can do, since we don't know the user's identity anymore. But we don't throw now, FWIW. Also, there's now a static event that gets raised when there's a validation exception if the app does want to know about them.

from cookietempdata.

Can I confirm the code that prevents the CryptographicException being thrown. Is the fix for this is just the Unprotect

    byte[] Unprotect(string value, HttpContextBase ctx)
    {
        if (String.IsNullOrWhiteSpace(value)) return null;

        var prefix = value[0].ToString();
        var purpose = GetMachineKeyPurposeFromPrefix(prefix, ctx);
        if (purpose == null) return null;

        value = value.Substring(1);
        var bytes = Convert.FromBase64String(value);
        try
        {
            return MachineKey.Unprotect(bytes, purpose);
        }
        catch (CryptographicException ex)
        {
            if (ValidationException != null)
            {
                ValidationException(this, ex);
            }
            return null;
        }
    }

from cookietempdata.

and then the BrockAllen.CookieTempData.dll can then just be dropped in to the Identity Server WebSite bin folder?

from cookietempdata.

I suppose a little back history would be useful in case anyone else is browsing and finds the issue. They can then possibly match their scenario to mine.

I'm using IdPSrv v2 -> ADFS -> SharePoint.

IdPSrv exists on two servers with load traffic manager serving requests.
ADFS is farm with Primary and Secondary and two Proxies.
SharePoint has a single WFE.

When I log in I'm passed around and eventually hit SharePoint. I wait for just over 50 minutes (45 minutes is fine) and then click on a page. I get passed back to IdPServ and the olde cryptographic operation leaps out.

from cookietempdata.

@ChewYoungPen if you think there's still a bug or problem, open a new issue so we can discuss. thx,

from cookietempdata.