Topic on Talk:Requests for comment/Content-Security-Policy

@Bawolff: I was experimenting a bit with this new setting and it works as far as I can see. However it will be nice to be able to add something like "www.google.com/recaptcha" to the "script-src" parameter instead of just "www.google.com" to allow for an even more fine-grained control.

In theory i think that should work. Note though, that in CSP, www.google.com/recaptcha would be only precisely that page (There's some special rules for redirects also). You'd need to do www.google.com/recaptcha/ for all js pages starting with that prefix.

I think ideally the user wouldn't add this, but the recaptcha extension would use the ContentSecurityPolicyScriptSource hook to add this (Possibly the hooks for extensions could be thought out more. Maybe we need a method of OutputPage (or even ParserOutput) to add domains to CSP policy only for specific pages)

Thanks a lot for your comment. Well I was kinda hoping that "www.google.com/recaptcha/" would cover all of the scripts coming trough that path but in the end I am with you that the Recaptcha module to the ConfirmEdit extension should cater for it. From your reply I see two tasks need to be created: one for MediaWiki about adding a method to be able to allow extensions use it, which in turn is the second task for the ConfirmEdit extension (actually using it). I believe that you are more proficient to create a meaningful task when it comes to the first one.

So, "www.google.com/recaptcha/" with a / should cover all paths for recaptcha. In CSP, paths ending in / are considered to mean the directory, where paths that don't end in / mean exact match (like a file).

Thanks for bumping me. You are right, adding "www.google.com/recaptcha/" allows for a more narrow restriction of what may be loaded. Still the other two tasks need to be created since these are improvements to be done?

So there is currently a hook extensions can use, but its probably not ideal for that usecase. A more fine-grained ability (i.e. via OutputPage) still needs to be done.

At this stage, I'm primarily focusing on getting the minimum needed to get the initial deployment done on Wikimedia, but I also definitely want to ensure all the necessary pieces are there for non-wikimedia deployments, including proper extension hooks.

I figured that it might be preferable to have tasks at phabricator for this. I am far from trying to change current plans. In the end I very much value your overall work on and for MediaWiki and trust your ways of proceeding.