Nuno G. de M created DELTASPIKE-832:
---------------------------------------
Summary: 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
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)
