Hi Michael,

Can you first clarify us that the asset url is not the edit url, so something like this: [YOUR-HOST-HERE]/EPiServer/CMS/Content/globalassets/en/alloy-meet/alloymeet.png,,61_62?epieditmode=False BUT url is like this: /globalassets/alloy-meet/alloymeet.png when trying to acces an asset not logged in.

If the url is not edit but the "real public url", do you get the RequireNonce even if trying to access an asset with another browser in private mode (just to rule out possible cookies from bad / aborted logins using OIDC)?

This is an old posting issue with IdentityServer3 https://github.com/IdentityServer/IdentityServer3/issues/542 (from year 2015) but there is the same issue and if scroll to the point where Kentor.OwinCookieSaver is mentioned it had fixed eventually the issue for the reporter of the issue.

We are still using the Kentor.OwinCookieSaver in our OIDC implementations, so you would need to add the package https://www.nuget.org/packages/Kentor.OwinCookieSaver/ to your solution and add this to your OWIN startup Configuration method before any OWIN stuff:

app.UseKentorOwinCookieSaver();

Kentor.OwinCookieSaver GitHub project: https://github.com/Sustainsys/owin-cookie-saver

Thanks for the reply Antti.

I am using the "real public url" and I have been testing with the browser in private mode. I have tried the OwinCookieSaver in the past and no luck. I see that the cookie is not being set that I am authenticated but I am not sure why.

Mike

I'm assuming the assets are "protected" and don't have read access for Everyone?

Correct. If I use the address that EPiServer gives me http://xxx.dxcloud.episerver.net it seems to work fine. However, if I use our custom domain name it does not work.

I think that hostname is without Cloudflare CDN so it probably has something to do with that. You can try hosts file to the IP of the dxccloud name and validate that it is a CDN issue and not something with your app configuration.

We are using DXC. My understanding is the Host entry would not affect us.

Hi Michael

I have the same problem. Did you find a solution?

We did find a solution to the problem. It was something to do with the CDN.

From EPi.. 
"Product Development Engineers mentioned that they are looking at a code change for not stripping the set-cookie for requests with CF-Cache-Status: BYPASS."  

"Cloud Flare has deployed a fix for your issue so they will no longer be stripping the cookie but a config change does need to be made to your DXC environment which will be taken care of engineering. Here is the response I just got from them:

Cloudflare has deployed their bugfix now, "CF-Cache-Status: BYPASS" will have the cookies sent through. Things that are not cached but still sent through the caching-infrastructure on their end, resulting in "CF-Cache-Status: MISS" will still not have any cookies sent through.
For this to work, "Origin Cache Control: On"-pagerule can applied to the customers zone now to make pages with "Cache-Control: private" headers bypass the Cloudflare cache completly, which would result in "CF-Cache-Status: BYPASS" and let through the authentication-cookies.

So engineering will be updating your Cloud Flare page rules to set "Origin Cache Control: On" which will finish the fix, once I get word this change is complete I will let you know.

So the change was made and it fixed it for us so I would contact EPi Support. However, we are experiencing some other issues that I am not 100% sure are not related to this. We are still working with EPi on a ticket but to this point we don't have a resolution.

Mike