[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153790#comment-15153790
 ] 

Sean Flanigan commented on DELTASPIKE-1074:
-------------------------------------------

Using default/LAZY mode, the other changes for '?' and '&&' in setUrlParam() 
seem to be fine.

> Severe problem in setUrlParam() (windowhandler.js)
> --------------------------------------------------
>
>                 Key: DELTASPIKE-1074
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1074
>             Project: DeltaSpike
>          Issue Type: Bug
>          Components: JSF-Module
>    Affects Versions: 1.5.3
>            Reporter: Sean Flanigan
>            Assignee: Thomas Andraschko
>             Fix For: 1.5.4
>
>
> I noticed a potential problem with the URI manipulation while reviewing 
> https://github.com/apache/deltaspike/commit/323c7d38e9d949385eb9d90c47e8971548ab5ed4
>  :
> > {{a.href = uri.replace('?&', '?').replace('&&', '&');}}
> I think it's only safe to coalesce multiple '&'s in the query part (after 
> '?), not in the path path (before '?'). In the path part, '&'s are just 
> characters, not parameter delimiters.
> Also, it's possible that the URI could be like this:
>   {{?&&&dswid=1234&&&}}
> with more than two ampersands in a row, perhaps at the beginning of the query 
> string.
> (Attn: [~tandraschko])
> EDIT: It looks like [this 
> commit|https://github.com/apache/deltaspike/commit/323c7d38e9d949385eb9d90c47e8971548ab5ed4]
>  has totally broken {{setUrlParam()}}, because 
> {{dswh.utils.generateRequestToken()}} generates {{requestToken}} as a number, 
> but {{setUrlParam()}} now assumes that {{parameterValue}} is a string, and 
> tries to call {{replace()}} on it. This leads to errors like this:
> http://localhost:49178/zanata/javax.faces.resource/deltaspike/windowhandler.js.seam
>  10:413 Uncaught TypeError: b.replace is not a function
> I think this wasn't discovered in earlier testing because 
> {{windowhandler.js}} seems to be aggressively cached. I had some trouble 
> convincing Chrome to reload {{windowhandler.js}}. 
> If possible, I would suggest including a hash value in the URL generated by 
> {{<ds:windowId/>}} and {{windowhandler.html}}, eg something like {{<script 
> type="text/javascript" 
> src="/javax.faces.resource/windowhandler.js?hash=871623874619283469"></script>}},
>  where the hash is generated from the contents of {{windowhandler.js}}, to 
> allow aggressive caching without risk of missing changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to