[
https://issues.apache.org/jira/browse/DELTASPIKE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved DELTASPIKE-832.
------------------------------------------
Resolution: Fixed
> Javascript assert windowId not resilient enough
> -----------------------------------------------
>
> Key: DELTASPIKE-832
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-832
> Project: DeltaSpike
> Issue Type: Bug
> Components: JSF-Module
> Affects Versions: 1.2.1
> Reporter: Nuno G. de M
> Assignee: Thomas Andraschko
> Fix For: 1.4.0
>
>
> The issue is with the algorithm used by the delta spike LAZY mode to identify
> the dswid in the request parameter of a window.
> We have a use case scenario where we open a URL for a view in an iframe by
> doing something as iframe.src / iframe.contentwindow.location.href = url.
> As opposed to doing a standard JSF form postback, this creates a get request
> for the URL. One of the request parameters that we have in our GET request
> is itself a small url.
> Say that we do a get:
> ifram.src =
> '/pageToOpen/whateve.xhtml?param1=whatever&loginUrl=/pathToSomeOtherUrl,xhtml?dswid=56&dswid=78787'
> OK. If you use a browser to decompse the query params of this get request you
> would get:
> param1=whatever
> loginUrl=/pathToSomeOtherUrl,xhtml?dswid=56
> dswid=78787
> This means we have three request parameters, param1, loginUrl and dswid.
> The algorithm:
> function getUrlParameter(name) {
> var url = window.location.href;
> var vars = url.split(/&|\?/g);
> for (var i=0; vars != null && i < vars.length; i++) {
> var pair = vars[i].split("=");
> if (pair[0]==name) {
> return pair[1];
> }
> }
> return null;
> }
> Will wrongly detect the dswid=56 as the window id of the request URL, and it
> will decide that it is different from window.name of the iframe, which in
> this case would actually have been 78787.
> This triggers the page to be double loaded due to the incorrect window id
> determined by the assert window id.
> One possible way to fix this issue, may be to make use of the browser
> capabilities to parse URLs.
> If you were to create an <a> anchor object e.g.
> var a = jQuery('<a>', { href:uri } )[0];
> You then can use the anchor object properties such as a.path and a.search to
> get the diffenrent components from the wndow.location.href.
> After that, you can make an accurate loop over the query parameters by
> spliting the a.search by &.
> Careful that the first element of the search part of the anchor, when not
> empty alway carries the ?, so you might want to do a.search.substring(1).
> Finally on the spllitted array by (&) you can loop over the elements, split
> each by '=' and then you will be accurately be able to know if any of the
> query parameters actually was a dswid.
> The current algorithm is not 100% accurate and can lead to page double
> loading if incrrectly parsing the URL.
> If possible, could you enhance the ds:windowid component to optinally render
> the javascript without using the compressed javascript?
> In order to figre out what was happening with the double load I had to create
> a render extending your base render and with resource depdency on the
> uncompressed javascript.
> Many thanks for all the help.
> Kind regards.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
