JSINFO moved to <meta>

[fjf2002]

JSINFO moved to a HTML <meta> tag, to allow a strict CSP.

Contributes to the discussion at #3788.

CAN work if there are no inline JavaScripts that instantly would need the JSINFO variable.

I have to admit already the DokuWiki default template has inline JavaScript; but does not use the JSINFO variable.

Let's put it this way: When you used an inline script in the past (that gets executed instantly), you could not rely on neither lib/exe/jquery.php nor lib/exe/js.php (because these are external and deferred). Now the JSINFO variable gets added to that list, too.

[fjf2002]

I observe: It could potentially get even simpler:

• Don't set the <meta> tag at all
• Put something like echo "const JSINFO = " . json_encode($JSINFO, JSON_THROW_ON_ERROR) . ";"; into js.php.

But then JSINFO.id (and potentially more variables from plugins?) wouldn't get set (?)

[splitbrain]

why the base64 encoding?

[fjf2002]

Well this PR was just thought as a quick proof-of-concept. I used base64 as kind-of quick means to safely escape the string properly for use in the HTML meta attribute. htmlspecialchars does not escape double quotes, so that would fail when constructing the meta tag using double quotes.

Feel free to suggest anything different.

[splitbrain]

Well this PR was just thought as a quick proof-of-concept.

Not to rain on your parade, I appreciate your desire to help, but I can do a quick proof of concept myself - no problem. The bigger task is to bring it to a state where it works well enough to be merged with confidence and for that a quick proof of concept PR is not really helping much.

[splitbrain]

The JS dispatcher runs without a session and the results are meant to be cacheable. So no user dependent information (like the signature) can be set here.

[fjf2002]

Suggestion: Add SIG into JSINFO? See the updated PR.

[fjf2002]

I'll have to admit I adapted the function toolbar_signature(). At least the test case will have to be adapted, too.

[fjf2002]

OK, I've made the <meta> tag usage W3C-validator-conformant, and used htmlspecialchars to encode.
For decoding, there does not seem an easier solution than $('<div/>').html(...).text() .

[mprins]

You may want to explore using a script tag with base64 encoded src attribute instead, of course that introduces async behaviour to these global variables

[fjf2002]

@mprins:

You may want to explore using a script tag with based encoded src attribute instead, of course that introduces async behaviour to these global variables

Thanks for the suggestion. I did not think of that. If I understand you correctly, you think of something like <script src="bWVoaA=="></script> ?

That actually passes the W3C validator.

However my browser tries to load that resource from https://my-dokuwiki-base/bWVoaA== and fails. Not nice.

Using a data-uri brings us back to the strict CSP header problem.

[mprins]

@fjf2002 indeed <script defer="defer" src="data:text/javascript;base64,Y29uc3Qgb2xFbmFibGU9dHJ1ZTtj..." nonce="..." and add the nonce to the CSP header, see also #4220

[fjf2002]

@mprins: Thank You for your reply. However my point was: I simply thought passing a bunch of variables (NS, JSINFO, and SIG) could be possible in an EASY way, AVOIDING the neccessity of a nonce.