[ 
https://issues.apache.org/jira/browse/SHINDIG-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655780#action_12655780
 ] 

Tim Moore commented on SHINDIG-89:
----------------------------------

I just got bitten by this fix. I wasn't expecting it to html-escape the return 
value of Prefs.getString() (which I am using in a URL query string generated in 
JavaScript). Pref values should absolutely be escaped when they are substituted 
directly into content, but not when they are retrieved using the JavaScript 
API. If it's not documented in the spec, there's no reason to expect that an 
implementation would do this. By having to explicitly unescape pref values in 
my javascript code, I'm risking portability problems with other implementations 
that don't do this. If you think it's the right thing to do, then it should 
definitely be explicit in the spec, but I'd argue that it's not, since there's 
no way to know whether these pref values are going to be treated as literal 
HTML or something else.

> Prefs / view parameter escaping
> -------------------------------
>
>                 Key: SHINDIG-89
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-89
>             Project: Shindig
>          Issue Type: Improvement
>          Components: Features (Javascript)
>            Reporter: Kevin Brown
>            Assignee: Kevin Brown
>         Attachments: escaping-patch.patch
>
>
> Currently, we do not escape gadgets.Prefs or gadgets.views parameters.
> This could potentially result in exploits of data by malicious outside sites.
> To remedy this, I propose the attached patch.
> As it stands, the spec is silent on the escaping issue, but in practice 
> gmodules.com already does this escaping for user prefs and I suspect that 
> other container sites do as well.
> I've also included an unescaping mechanism that I think should ultimately be 
> proposed to the spec discussion group, but that's a later issue.
> Feedback is much appreciated. If no one objects, I'll commit this change 
> tomorrow morning.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to