[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bugs-dist
Subject: [Bug 116406] frame inside frame recursion at blog of SAP manager
From: Frank Reininghaus <frank78ac () googlemail ! com>
Date: 2008-04-19 23:30:17
Message-ID: 20080419233017.14416.qmail () ktown ! kde ! org
[Download RAW message or body]
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.kde.org/show_bug.cgi?id=116406
frank78ac googlemail com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |frank78ac googlemail com
------- Additional Comments From frank78ac googlemail com 2008-04-20 01:30 -------
I saved this page with Firefox using "Save page as/... Webpage, complete" to see \
what's going on. This <iframe>-recursion seems to be due to more than one problem \
(both in Konqueror and in the page itself; all I write here applies to Konqueror \
3.5.8 and SVN trunk revision 798811).
The short version is:
1. Protection against recursive inclusion of <iframe>s fails if JavaScript \
(document.location.replace) is involved (Firefox stops after 10 recursions in this \
case).
2. The SAP webpage uses document.location.replace for the file in the <iframe>, not \
for the parent which was probably intended.
3. A regular expression check of parent.location.href fails in the file in the \
<iframe> in Konqueror, but apparently not in Firefox.
Here is the long version:
It seems that Konqueror actually has some protection against the inclusion of an HTML \
page in itself using <iframe> as can be seen in this example (save as \
recursive-iframe.html):
<html><head><title>konqi test</title></head>
<body>
<p>This is the top of a new HTML file.<p>
<p>An iframe starts below this line:</p>
<hr />
<iframe src="recursive-iframe.html" width="95%" height="95%">
</iframe>
</body>
</html>
The page is included just once, then the recursion stops (Firefox stops the recursion \
even earlier and doesn't include the file at all).
One of the problems in Konqueror is that this protection does not work if the \
<iframe> includes another HTML file which then replaces itself by the first HTML file \
using JavaScript (document.location.replace ()). To see this, save this file as \
recursive-iframe-2a.html:
<html><head><title>konqi test</title></head>
<body>
<p>This is the top of a new HTML file.<p>
<p>An iframe starts below this line:</p>
<hr />
<iframe src="recursive-iframe-2b.html" width="99%" height="99%"></iframe>
</body>
</html>
and this as recursive-iframe-2b.html:
<html><head><title>konqi test</title>
<script type="text/javascript" language="javascript">
document.location.replace('recursive-iframe-2a.html')
</script>
</head>
<body>
<p></p>
</body>
</html>
You get an infinite <iframe> recursion in Konqueror (Firefox stops after 10 \
recursions). This is essentially what happens when that SAP page is opened in \
Konqueror.
The situation in the SAP page is similar:
The HTML file contains an <iframe> (just like the example recursive-iframe-2a.html), \
and the included file contains in its <head> the following JavaScript code:
<script type="text/javascript" language="javascript">
try {
var pattern = /^https:\/\/(www(\d{3})?|wwwn|admin|webservice)\.sdn\.sap\.com/;
if (!pattern.test(parent.location.href)) {
document.location.replace('https://www.sdn.sap.com/irj/sdn/weblogs?blog='
+ escape(document.location.pathname)
+ escape(document.location.search));
}
} catch (e) { }
</script>
This is apparently a check that should make sure that the page is opened from the SAP \
webserver and not from some local copy. The mistake in the page is that it then uses \
'document.location.replace ()' (instead of replacing the location of the parent) in \
case of failure, i.e., it replaces the contents of the <iframe> with the first HTML \
file which contains the <iframe>. This leads to the recursion, but only in Konqueror!
The strange thing is that the regular expression check \
(!pattern.test(parent.location.href)) fails in Konqueror (but apparently not in \
Firefox). It's not easy to analyse this with a local copy of the page because \
parent.location.href yields something different then. I can just say that \
parent.location.href yields the right offline URL if I use the local copy and that \
the regular expression check works OK if I replace 'parent.location.href' with the \
actual URL
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1700
My first guess would be that parent.location.href is for some reason not equal to \
this URL, but the easy check
document.write ("parent.location.href = " + parent.location.href);
requires write access to the file on the web server.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic