in reply to Re^4: LTR character in links
in thread LTR character in links

The source in my home node has this... 

<p>CPAN Releases</p>
<p><a href="https://metacpan.org/pod/Business::Stripe::WebCheckout">Bu
+siness::Stripe::WebCheckout</a><br />
<a href="https://metacpan.org/pod/Business::Stripe::Subs&#x200E;crip&#
+x200E;tion">Business::Stripe::Subs&#x200E;crip&#x200E;tion</a><br />
<a href="https://metacpan.org/pod/Business::Stripe::Webhook">Business:
+:Stripe::Webhook</a></p>
<p><a href="https://metacpan.org/pod/AI::Embedding">AI::Embedding</a><
+/p>

[download]
It is the &x200E; characters that should not be there...

They were not put there when I edited my profile but somehow PM is adding them and I cannot get rid of them...do they not look like that to you?

I've turned off all browser extensions and checked on another machine with a freshly installed Chrome browser with no extensions.

Replies are listed 'Best First'.
Re^6: LTR character in links @pmdev
by ikegami (Patriarch) on Jun 21, 2023 at 00:23 UTC

    but somehow PM is adding them and I cannot get rid of them.

    Indeed, I can reproduce for profiles pages. For profile pages (but not for SoPW pages), instances of script are replaced with s&#x200E;crip&#x200E;t.

    This is presumably a security measure. However, I can't imagine why this measure would be needed for profile pages if it isn't needed for SoPW pages. I therefore consider this a bug.

    Workaround: Use &#x73;cript instead of script. (&#x53; for an uppercase S.) For example, 

    <a href="https://metacpan.org/pod/Business::Stripe::Sub&#x73;cription"
+>Business::Stripe::Sub&#x73;cription</a>

    [download]

    The hack is applied after the expansion of [mod://] and similar, so they can't be used as a workaround.

[reply]
[d/l]
[select]
      For profile pages (but not for SoPW pages), instances of script are replaced with s‎crip‎t.

      This is presumably a security measure.

      Exactly right. From the very beginning, the user display page contained code to neutralize embedded javascript code. Originally, it attempted to "quote" any occurrence of a <script element in the user node content. But in December 2004, it was changed to the current technique, which blindly mangles any occurrence of script.

      I can't imagine why this measure would be needed for profile pages if it isn't needed for SoPW pages.

      I'm not sure but I believe this is because user pages are — or were — granted somewhat more freedom in terms of what HTML elements are allowed. iinm, regular writeup nodes are already strict enough that additional filtering for <script> is unnecessary.

      Today's latest and greatest software contains tomorrow's zero day exploits.
[reply]
[d/l]
[select]

        granted somewhat more freedom in terms of what HTML elements are allowed

        Makes sense, thanks.

[reply]
      Workaround: Use &#x73;cript instead of script.

      That works and is now installed - thanks ikegami

      Of course, it would still be good if pmdev could correct the bug and still allow JavaScript to be turned off...
      Perhaps, instead of looking for /script/, PM could check for /script( |>)/

[reply]
[d/l]
[select]
      In User Settings, I see a switch "Disable some JavaScript on homenodes". Maybe it is related?
[reply]

        Maybe 15 years ago I found a homenode exploiting the ability to add JavaScript to do some nasty things. I can't remember exactly what happened as a result but my gut tells me that this was when the option for scrubbing 'risky' things from homenodes by default was set.

[reply]
        I see a switch "Disable some JavaScript on homenodes

        That one doesn't affect it but the next one does - Don't filter risky HTML from monks' homenodes - however, this has to be set by people viewing the home node so it doesn't really help. It is there to turn off unwanted JavaScript in other monks' home nodes but it's picking up my non-JavaScript module name!

[reply]

In Section Perl Monks Discussion