On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
>
> when a new window or tab is opened by a page it normally has a
> "window.opener" property that points to the window object of the
> original tab.
Indeed, this is now specced.
> If an origin check fails when comparing the locations of the old w
On 20/03/07, Thomas Broyer <[EMAIL PROTECTED]> wrote:
2007/3/20, liorean:
> Some thing I would like to add here, is that your "solution" doesn't
> do anything to solve the actual l problem case. Even if window.opener
> would be read only, that is just a reference to a window object. Even
> if tha
If the primary domain is www.example.com and the other domain is
help.example.com the UA clearly should allow them to communicate by
request. Believe me, nulling window.opener if origin check fails will
break MANY sites.
This is not the point I am making, and I feel we are not
understanding on
2007/3/20, liorean:
Some thing I would like to add here, is that your "solution" doesn't
do anything to solve the actual l problem case. Even if window.opener
would be read only, that is just a reference to a window object. Even
if that property would be read only you could still write to the
lo
>> 1) Either it is your responsibility to handle the nulling of the
>> property *or*
>> 2) It is the UA's.
>
> The UA can not do this. It would break legacy pages by resetting
> window.opener if content comes from a different server.
If this is a security point, which I take from the subject
"w
I was clearly mislead by the "window.opener and security" title then
On 20 Mar 2007, at 15:51, liorean wrote:
On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:
As was clearly stated, I showed a workaround and then suggested it
should be up to the UA to handle this situation.
It is not helpful
On 20 Mar 2007, at 15:45, Hallvord R M Steen wrote:
1) Either it is your responsibility to handle the nulling of the
property *or*
2) It is the UA's.
The UA can not do this. It would break legacy pages by resetting
window.opener if content comes from a different server.
If this is a security
On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:
As was clearly stated, I showed a workaround and then suggested it
should be up to the UA to handle this situation.
It is not helpful to deliberately misunderstand points, and quote
them out of context. I suggest you re-read my mail.
You showed
1) Either it is your responsibility to handle the nulling of the
property *or*
2) It is the UA's.
The UA can not do this. It would break legacy pages by resetting
window.opener if content comes from a different server.
I personally think the UA should handle it (as stated previously)
**BUT** i
> > >
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem
>
> javascript: void(window.open( 'http://hallvord.com/temp/redir.php'))
I don't know what GMail is doing, but I think a
window.open('','_self') would destroy the original window.opener.
That's a
It would appear that at least the WebKit team agree about the
window.opener being read-only.
It has resisted all attempts by me to null it or re-assign it, and as
soon as the domains no longer match exceptions are thrown.
From a security point of view I think this is sufficient to prevent
I think you are deliberately missing the point now...
On 20 Mar 2007, at 14:50, Hallvord R M Steen wrote:
On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:
Anyway, for use case 1 - If you are worried about phishing attacks,
you should be using some sort of
onunload handler trapping to null wi
2007/3/20, Hallvord R M Steen <[EMAIL PROTECTED]>:
On 20/03/07, timeless <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:
> >
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem
> I believe you'll find that Gmail doe
On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:
Anyway, for use case 1 - If you are worried about phishing attacks,
you should be using some sort of
onunload handler trapping to null window.opener.
Yet you are arguing that it should be impossible to set window.opener.
If you had your way tha
On 20/03/07, timeless <[EMAIL PROTECTED]> wrote:
On 3/20/07, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:
>
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem
I believe you'll find that Gmail does not have this problem, because
when it uses window.op
Well, I don't think it is off-topic.
You are trying to justify writing to a property I think should be
read-only.
I am asking you why you think this should be possible.
Anyway, for use case 1 - If you are worried about phishing attacks,
you should be using some sort of
onunload handler trapp
On 3/20/07, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem
I believe you'll find that Gmail does not have this problem, because
when it uses window.open, it opens a gmail page which then triggers a
serve
On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:
Well, window.opener is conceptually a link from child to parent.
Can you give a valid use-case for adoption of the child to another
parent?
Again: We are off-topic. This isn't what I'm trying to discuss in this thread.
However, here are two us
Well, window.opener is conceptually a link from child to parent.
Can you give a valid use-case for adoption of the child to another
parent?
On 20 Mar 2007, at 13:00, Hallvord R M Steen wrote:
On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:
window.opener should be read-only and attempting
On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:
window.opener should be read-only and attempting to write to it
should throw an exception.
I don't really see why setting opener would be dangerous, so I
disagree that it should throw. Anyway, that is a different issue. What
I'm talking about i
2007/3/20, Gareth Hay <[EMAIL PROTECTED]>:
window.opener should be read-only and attempting to write to it
should throw an exception.
It was possible to set window.opener in IE, alas, I do not remember
which version :(
But it has been fixed, AFAIK.
Regards,
Rimantas
--
http://rimantas.com/
window.opener should be read-only and attempting to write to it
should throw an exception.
This is a similar issue to window.history, in certain browsers you
can write to this with js. It has no effect, but does persist across
domains. The webkit team decided to just throw an exception if a
Hi,
when a new window or tab is opened by a page it normally has a
"window.opener" property that points to the window object of the
original tab.
This happens whether the new window is opened by a JavaScript calling
window.open or by a link or form with target attribute set.
If an origin check f
23 matches
Mail list logo
