Refactor addCss / addJs / tailscript into something visibly safer

[stwalkerster]

In PR 285, @deltaquad wrote:

Is there any way in which the changes in includes/Tasks/PageBase.php could have something injected by cookie, or user set setting? I'm asking more than looking because I don't know all the pages to look at.

Update: I do see templates/base.tpl which requires the js/css to come from our tool, I'm just worried there is still a way through dns/request modification that it could be screwed with.

I replied:

I think there probably is some tidy-up needed around both the addCss and addJs calls, and also the tailscript functionality. Reviewing it all myself, I'm happy my current usage of it is fine (with the exception of the U2F code, which I will poke a bit), but I'm not happy with it's encouragement of good practice.

In truth, those functions shouldn't be in this PR; they're not used yet; and neither is the tailscript functionality, so I'm happy that it's not possible to exploit it here, and it's also not used in the rbac branch. Both are used in the OTP/OAuth creation code though, neither of which are up for review yet.

Originally posted by @stwalkerster in #285 (comment)

[stwalkerster]

I'm honestly not sure what else could be done here - unless we set flags on the libraries to load on each request, I don't see a clean way around this without loading every bit of JS on every page load.

[stwalkerster]

addCss is now removed, tailScript I can't see a sane way of removing without adding the U2F library directly in the template itself (which I feel lends itself to more risk) or moving all the JS script loads into the header, which isn't recommended for performance.

[stwalkerster]

I think it's as good as we're gonna get this, so I'm going to take this off the newinternal list, and leave it on the tech-debt list pending better ideas.