Closed
Bug 56053
Opened 24 years ago
Closed 24 years ago
can't set location.href across domains (setting location works)
Categories
(Core :: Security: CAPS, defect, P3)
Core
Security: CAPS
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: spam, Assigned: security-bugs)
References
()
Details
2000100918 linux
go to http://www.sol.no/nyheter/
In the left menubar there is a couple of grey boxes, the top one reads
"Aviskiosken". Click the image-link there (same wording)
A small tall window appears, with some top tabs and selectbox for various
national and international newsmedia.
Click one of the items in box - it works, the page loads in main window.
Now click one of the tabs.
A new box with various other selections appear.
Click one of those, and from now on every selection you perform only return an
error, also if you go back to the initial tab. The links that formerly worked
work no more.
JavaScript error:
line 0: uncaught exception: [Exception... "Access to property denied" code:
"1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)" location:
"http://www.sol.no/nyheter/cgi-bin/avisoversikt.cgi Line: 11"]
NC 4.75 has no problems with it. Trying DOM level 0 for starters.
Comment 1•24 years ago
|
||
Ok, so here's what's happening here. Clicking on the "Aviskiosken" link brings
up a small window from www.sol.no. Clicking on one of the items in the list in
the small window will replace the main window with a different URL, for example,
'http://www.adresseavisen.no/'. Now, the next time one of the items in the list
in the small window is clicked the small window executes this code:
opener.location.href="...";
and that code fails since the window where this happens is from 'www.sol.no' and
the 'opener' is now from 'www.adresseavisen.no'.
Mitchell, is this intentional? It seems like mozilla would need to allow that
anyone can *set* location.href in all cases without checking for same-origin for
this site to function, sounds scary scary to me.
Assignee: jst → mstoltz
Here another, similar case:
-From a new window with no URL loaded: Go to http://www.nostatic.org/grip/
-Scroll down the upper frame till the "Download" section, and click link "here"
This loads the sourceforge page for the app in upper frame. The bottom frame
is still the one from the grip page. Notice that the back-button is disabled.
(This is probably the good old "back doesn't work with frames" bug.
-Now: click image link "Groove" in bottom menu frame.
The link is:
javascript:OpenTop('http://www.nostatic.org/grip/grip.html')
-Clicking it after the sourceforge frame is loaded spawns only the error, and
nothing loads:
(Clicking the link while still at the original "grip" url loads the frame OK.)
JavaScript error:
line 0: uncaught exception: [Exception... "Access to property denied" code:
"1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)" location:
"http://www.nostatic.org/misc/sound.html Line: 8"]
NC 4.75 has no problems with this. Both "Back" and the links all work OK.
Comment 4•24 years ago
|
||
Mozilla doesn't let you set location.href for a window that is currently at
another domain, but it does let you set location. IE and NS4 allow setting
either location or location.href.
I'm testing this by typing/pasting
javascript:void(window.open("http://www.mozilla.org/"));
into a browser window at a webpage and then pasting
javascript:void(opener.location.href="http://www.slashdot.org/");
into the window that pops up.
(I filed bug 59570 for a recent regression in the console error printed after
pasting the second url.)
Component: DOM Level 0 → Security: CAPS
OS: Linux → All
Hardware: PC → All
Summary: links stop working → can't set location.href across domains (setting location works)
Assignee | ||
Comment 9•24 years ago
|
||
Mass changing milestones to Moz0.9.1. Many of these bugs are dependent on the
XPConnected DOM and its associated security UI changes.
Target Milestone: --- → mozilla0.9.1
Updated•24 years ago
|
QA Contact: desale → ckritzer
Comment 10•24 years ago
|
||
QA Contact -> ckritzer@netscape.com
Assignee | ||
Comment 11•24 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•24 years ago
|
||
Yes, fixed. Tested on a current CVS build, Linux: Now it works :)
Comment 13•24 years ago
|
||
Hmmm...
This seems to be working fine on 2001-05-22-xx builds for Linux & Windows, but
not on the 2001-05-21-21 build for Mac (don't have Mac bits for 22nd yet). I'll
check again after I get the Mac bits for the 22nd.
Comment 14•24 years ago
|
||
Okay, works on the 2001-05-22-09-trunk MOZILLA Mac bits
Marking VERIFIED FIXED on:
-MacOS91 2001-05-22-09-trunk MOZILLA
-Win98SE 2001-05-22-06-trunk
-LinRH62 2001-05-22-05-trunk
Status: RESOLVED → VERIFIED
Depends on: 82159
You need to log in
before you can comment on or make changes to this bug.
Description
•