New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In sandbox mode, window.opener doesn't work when children are from different domain #8100

Open
davidrevmakx opened this Issue Nov 30, 2016 · 23 comments

Comments

Projects
None yet
@davidrevmakx

davidrevmakx commented Nov 30, 2016

  • Electron version: 1.4.10
  • Operating system: Darwin x64

Expected behavior

When a popup pointed to a different domain from the parent is opened. window.opener should not be null. It is required for many OAuth authentication where the parent and the child (popup) is from different domains.

Actual behavior

When a popup is pointed towards the same domain window.opener is present but when its pointed towards a different domain window.opener is null

How to reproduce

main.js
app.on('ready', () => { console.log("ready"); const win = new BrowserWindow({webPreferences: { sandbox: true }}) win.loadURL('http://localhost:8888/index.html'); })

index.html
<a href="javascript:window.open('https://app.asana.com')">Click here</a>

window.opener is null at app.asana.com because the domain is different from the parent

@tarruda tarruda changed the title from window.opener doesn't work when children are from different domain to In sandbox mode, window.opener doesn't work when children are from different domain Nov 30, 2016

@tarruda tarruda self-assigned this Nov 30, 2016

@sivaram636

This comment has been minimized.

Show comment
Hide comment
@sivaram636

sivaram636 Jan 24, 2017

Any updates on this?

sivaram636 commented Jan 24, 2017

Any updates on this?

@manuth

This comment has been minimized.

Show comment
Hide comment
@manuth

manuth Feb 22, 2017

Same issue occured for me as I tried to connect to Deezer using their JavaScript-SDK.

Is there any way I can work around it?
Will you guys have some time left for having a look at it in the near future?
That'd be nice 😄

Thanks in advance

manuth commented Feb 22, 2017

Same issue occured for me as I tried to connect to Deezer using their JavaScript-SDK.

Is there any way I can work around it?
Will you guys have some time left for having a look at it in the near future?
That'd be nice 😄

Thanks in advance

@TheMSB

This comment has been minimized.

Show comment
Hide comment
@TheMSB

TheMSB Mar 9, 2017

Having a similar issues when trying authentication with Spotify, is there a flag or workaround we can use to still enable oauth popups?

TheMSB commented Mar 9, 2017

Having a similar issues when trying authentication with Spotify, is there a flag or workaround we can use to still enable oauth popups?

@quanglam2807

This comment has been minimized.

Show comment
Hide comment
@quanglam2807

quanglam2807 Mar 15, 2017

Same question with @TheMSB. quanglam2807/appifier#39: it affects Spotify, Feedly and a lot of web sites.

quanglam2807 commented Mar 15, 2017

Same question with @TheMSB. quanglam2807/appifier#39: it affects Spotify, Feedly and a lot of web sites.

@alexk111

This comment has been minimized.

Show comment
Hide comment
@alexk111

alexk111 Apr 10, 2017

+1. Getting issue reports from users trying to auth with Google account on many different web apps.

alexk111 commented Apr 10, 2017

+1. Getting issue reports from users trying to auth with Google account on many different web apps.

@Thomas101

This comment has been minimized.

Show comment
Hide comment
@Thomas101

Thomas101 May 17, 2017

We're also seeing the same behaviour in 1.7.1 when using the nativeWindowOpen option as described in the electron docs here

Thomas101 commented May 17, 2017

We're also seeing the same behaviour in 1.7.1 when using the nativeWindowOpen option as described in the electron docs here

@eyarz

This comment has been minimized.

Show comment
Hide comment
@eyarz

eyarz May 17, 2017

If someone need it, I made a repo to reproduce this bug:
https://github.com/eyarz/electron-new-window-bug

eyarz commented May 17, 2017

If someone need it, I made a repo to reproduce this bug:
https://github.com/eyarz/electron-new-window-bug

@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda May 17, 2017

Contributor

@eyarz thanks, I will try to have a look this week

Contributor

tarruda commented May 17, 2017

@eyarz thanks, I will try to have a look this week

@shimont

This comment has been minimized.

Show comment
Hide comment
@shimont

shimont May 23, 2017

Looking forward to seeing this bug fixed :)

shimont commented May 23, 2017

Looking forward to seeing this bug fixed :)

@Tahini-123

This comment has been minimized.

Show comment
Hide comment
@Tahini-123

Tahini-123 May 29, 2017

Any news? :)

Tahini-123 commented May 29, 2017

Any news? :)

@zcbenz zcbenz added the fixme/bug label May 31, 2017

@Amzul

This comment has been minimized.

Show comment
Hide comment
@Amzul

Amzul Jun 14, 2017

Also waiting here, :)

Amzul commented Jun 14, 2017

Also waiting here, :)

@gerges

This comment has been minimized.

Show comment
Hide comment
@gerges

gerges Jun 14, 2017

I've been wrestling window.open issues for the past day and a half, all to attempt to get Google and other OAuth to work. I've tried with electron's window.open implementation, initially planning bridge sync calls like window.opener.foo via ipc with node-fibers. Due to #9581 , that isn't an option. I also tried the new nativeWindowOpen, which is by far the most promising, but ran into this issue. After debugging my use case further I found something surprising... the window.opener is correctly set when the page first loads about:blank, but gets lost when it loads the url supplied to the BrowserWindow I'm curious if navigating from about:blank to another site is confusing chromiums security policy (as the window.opener would normally be unset when you change domains). //cc @kevinsawicki

gerges commented Jun 14, 2017

I've been wrestling window.open issues for the past day and a half, all to attempt to get Google and other OAuth to work. I've tried with electron's window.open implementation, initially planning bridge sync calls like window.opener.foo via ipc with node-fibers. Due to #9581 , that isn't an option. I also tried the new nativeWindowOpen, which is by far the most promising, but ran into this issue. After debugging my use case further I found something surprising... the window.opener is correctly set when the page first loads about:blank, but gets lost when it loads the url supplied to the BrowserWindow I'm curious if navigating from about:blank to another site is confusing chromiums security policy (as the window.opener would normally be unset when you change domains). //cc @kevinsawicki

@CptMaumau

This comment has been minimized.

Show comment
Hide comment
@CptMaumau

CptMaumau Jun 29, 2017

+1 can't add files from Google Drive in my app

CptMaumau commented Jun 29, 2017

+1 can't add files from Google Drive in my app

@Tahini-123

This comment has been minimized.

Show comment
Hide comment
@Tahini-123

Tahini-123 Jul 6, 2017

anyone? this has been open 7 months...

Tahini-123 commented Jul 6, 2017

anyone? this has been open 7 months...

@gerges

This comment has been minimized.

Show comment
Hide comment
@gerges

gerges Jul 7, 2017

I believe I was able to verify the domain change is the issue. If I call window.open("about:blank") I can see that window.opener is accessible. Once I call window.location.href = "https://www.google.com" I lose access. This is in fact not the way Chrome works. If you do the same in Chrome you'll always have access to window.opener but some calls will result in

Uncaught DOMException: Blocked a frame with origin "https://www.google.com" from accessing a cross-origin frame.
    at <anonymous>:1:23

Is it possible some of the old non-native window code is clearing window.opener? Or some other internal doing so?

gerges commented Jul 7, 2017

I believe I was able to verify the domain change is the issue. If I call window.open("about:blank") I can see that window.opener is accessible. Once I call window.location.href = "https://www.google.com" I lose access. This is in fact not the way Chrome works. If you do the same in Chrome you'll always have access to window.opener but some calls will result in

Uncaught DOMException: Blocked a frame with origin "https://www.google.com" from accessing a cross-origin frame.
    at <anonymous>:1:23

Is it possible some of the old non-native window code is clearing window.opener? Or some other internal doing so?

@haggaidavid

This comment has been minimized.

Show comment
Hide comment
@haggaidavid

haggaidavid Jul 11, 2017

+1 would love to see this one fixed

haggaidavid commented Jul 11, 2017

+1 would love to see this one fixed

@eyal55

This comment has been minimized.

Show comment
Hide comment
@eyal55

eyal55 Jul 11, 2017

+1 -looking forward to see this bug fixed.

eyal55 commented Jul 11, 2017

+1 -looking forward to see this bug fixed.

@MarshallOfSound

This comment has been minimized.

Show comment
Hide comment
@MarshallOfSound

MarshallOfSound Jul 11, 2017

Member

@haggaidavid @eyal55 Can we not "+1" issues, it adds needless email / notification spam. If you want to indicate your support for an issue please react using the 👍 reaction on the original issue report 😄

Member

MarshallOfSound commented Jul 11, 2017

@haggaidavid @eyal55 Can we not "+1" issues, it adds needless email / notification spam. If you want to indicate your support for an issue please react using the 👍 reaction on the original issue report 😄

@arkokoley

This comment has been minimized.

Show comment
Hide comment
@arkokoley

arkokoley Feb 2, 2018

+1 would love to see this one fixed

arkokoley commented Feb 2, 2018

+1 would love to see this one fixed

@sofianguy sofianguy added bug 🐞 and removed fixme/bug 🐞 labels Apr 4, 2018

@ryanflowers

This comment has been minimized.

Show comment
Hide comment
@ryanflowers

ryanflowers Jul 25, 2018

Hello, just checking in on this. I assume that there is no traction here as no one is updating the thread. @MarshallOfSound any insight as to whether anyone is actively looking into this? This is pretty limiting considering it blocks our auth flows. Any kind of status or work around info would be super helpful! Thank you in advance :)

Update: Just noticed @tarruda seems to be the assignee on this one so directing the questions his way. Thank again

ryanflowers commented Jul 25, 2018

Hello, just checking in on this. I assume that there is no traction here as no one is updating the thread. @MarshallOfSound any insight as to whether anyone is actively looking into this? This is pretty limiting considering it blocks our auth flows. Any kind of status or work around info would be super helpful! Thank you in advance :)

Update: Just noticed @tarruda seems to be the assignee on this one so directing the questions his way. Thank again

@BenjaminDobler

This comment has been minimized.

Show comment
Hide comment
@BenjaminDobler

BenjaminDobler Aug 1, 2018

I also have this issue with the new Apple MusicKitJS API. Authentication fails because window.opener is null. In my case i have a webview in my app which loads a page which includes MusicKitJS stuff. From there the apple music authentication is happening but fails at the last step because of window.opener = null. This prevents so maybe nice electron use cases. I hope this gets some traction.
If you need anything from me to reproduce the issue let me know.

BenjaminDobler commented Aug 1, 2018

I also have this issue with the new Apple MusicKitJS API. Authentication fails because window.opener is null. In my case i have a webview in my app which loads a page which includes MusicKitJS stuff. From there the apple music authentication is happening but fails at the last step because of window.opener = null. This prevents so maybe nice electron use cases. I hope this gets some traction.
If you need anything from me to reproduce the issue let me know.

@alexeykuzmin

This comment has been minimized.

Show comment
Hide comment
@alexeykuzmin

alexeykuzmin Aug 13, 2018

Contributor

@tarruda Are you actually working on this?

Contributor

alexeykuzmin commented Aug 13, 2018

@tarruda Are you actually working on this?

@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda Aug 14, 2018

Contributor

@alexeykuzmin I haven't looked into it yet.

Contributor

tarruda commented Aug 14, 2018

@alexeykuzmin I haven't looked into it yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment