Ability to pass JavaScript nonce via RenderIncludes()

[i4rilu]

Please implement an ability to pass nonce (random string - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script) via MiniProfiler.Current.RenderIncludes() method.

This would allow to apply Content-Security-Policy rules on the website and white-list MiniProfiler includes.min.js JavaScript as a safe one.

[NickCraver]

Yeah we could add this - just so I'm clear - is this asking for a MiniProfiler.Current?.RenderIncludes(Nonce: "mynonce") setup? If not, could you clarify with an example.

I'm also what @vcsjones thinks on adoption here :)

[i4rilu]

Yes, that's correct.
Additional parameter for MiniProfilerWebExtensions.RenderIncludes() extension method.

[vcsjones]

That seems useful. Would need to make sure that there is no caching of the script tags with the nonce. Perhaps another option to think about would be a factory somewhere, maybe on MiniProfilerBaseOptions that looks something like this:

public Func<HttpContext, string> CspNonceFactory { get; set; }

So that you only need to configure it once. It takes an HttpContext since there needs to be some coordination of the nonce between the script tag and whatever renders the CSP header. Just thinking out-loud here though.

I'm also what @vcsjones thinks on adoption here :)

Nonces are mostly well supported by everything except IE. Edge (the old Edge, not Edgium) does not support nonces on scripts that use src, only on inline scripts, but I think that's OK here.

[NickCraver]

I'm taking a peek at this now - it'd have to be on the per-provider options which makes things a bit more complicated. That's because HttpContext differs between ASP.NET and ASP.NET Core and Render lives in the shared lib. But, adding a parameter is also a breaking change...so we'll need some overloads here to handle it. I'm debating if we're getting too many parameters in there, but allocating an object every time isn't great either. Going to ponder options here for a hot second before adding more overloads (but that's likely most practical at the moment).

[NickCraver]

Hey all, sorry this lingered - how to version the RenderIncludes API was the vexing piece and I needed to consider a few more additions to it and what things collectively looked like.

After talking with @mgravell, we decided that the small class allocation on call is okay enough in the scheme of things - it's 1 class allocation and not a big one. I'll likely optimize the writing path in ASP.NET Core specifically as a follow-up (to eliminate the string allocation).

Can y'all please see if #465 does what you want here? Now that the blocker is gone, I'd like to merge this and dogfood on Stack Overflow this week before doing a NuGet release.