in reply to Re: Let users link in a javascript library
in thread Let users link in a javascript library

In response to private messages, yes, either of these changes would need to be well advertised. But there's no point in doing so until someone steps forward to do the work. And until someone does, we really oughtn't advocate that people allow perlmonks to execute javascript.
  • Comment on Re^2: Let users link in a javascript library

Replies are listed 'Best First'.
Re^3: Let users link in a javascript library (required)
by tye (Sage) on Apr 15, 2008 at 04:19 UTC

    For the sake of clarity, my proposal to properly filter javascript requires filtering HTML as well. So, yes, if you want to see what is going to happen, go to User Settings and turn on "Filter HTML of monks' homenodes".

    My impression is that the allowed tags are already pretty much where they can and should be.

    As a first step, we should turn on this setting for AnonyMonk (not as easy at one might guess, since I've tried before and failed). Another attempt is now on the top of my to-do list.

    - tye        

      My impression is that the allowed tags are already pretty much where they can and should be.
      I guess I'm misremembering, then. I thought we'd discussed allowing a broader range of things on homenodes. I wouldn't be drastically opposed to being restrictive initially, then seeing what people clamor for, but in principle I'd like to see monks have more artistic freedom on their homenode.
      My impression is that the allowed tags are already pretty much where they can and should be.
      In my previous response, I was assuming you meant just the Perl Monks Approved HTML Tags. I'd forgotten there were the additional tags allowed for homenodes. What are your concerns about external imgs? They'd allow ipaddr logging; is there any other concern?
        Cross-site request forgery.

        Since most users allow the browser to load images, an external image can be used to trigger an GET request to an arbitrary URL, and the browser sends all session cookies of the target domain to that URL. Without any interaction from the user.

        While state change on the server side should not be triggered by GET requests they often are. So it's safer to forbid them.

    A reply falls below the community's threshold of quality. You may see it by logging in.