Support cross-domain in both directions with single proxy page#30
Support cross-domain in both directions with single proxy page#30gerneio wants to merge 1 commit intojcubic:masterfrom
Conversation
|
Can you show me a live demo when this doesn't work and your code does? I'm not sure if I understand the use case. Usually, when I want two-direction communication I used two iframes (and this is how it's documented) if it will work with a single iframe that would be great and it will simplify the setup (also the documentation - README - will need to be updated). |
|
@jcubic So using your demos sites (https://jcubic.pl/sysend.php & https://terminal.jcubic.pl/sysend.php) to test the issue, just remove the proxy calls from one of the pages. To test, I used Chrome dev tools local overrides features and modified "https://jcubic.pl/sysend.php" so that the proxy lines were commented out (see attached PHP file: sysend.zip). I then opened both pages simultaneously and could send messages from "jcubic.pl" to "terminal.jcubic.pl", but nothing would be received if sent in reverse. I then did the local override for the "sysend.js" file to point to my modified version of the script, refreshed the pages, and then the messaging worked from either direction. Therefore it is possible to have only a single proxy in use. Just so you know, my use case is where I have full control over one web server, however the other I am only allowed a custom loaded JS file, but can't host any sort of proxy page. But the custom JS file is really all I need since I have full control of the other server/domain. |
|
Will this work when the iframe is on either of the domains? |
|
I Will test this and release it as the next feature version. Since if only one domain will need an iframe it would be a huge change. |
|
I believe so. It's the same principal in either direction.
Hector G. Bas III
…On Sun, Feb 13, 2022, 3:54 PM Jakub T. Jankiewicz ***@***.***> wrote:
Will this work when the iframe is on either of the domains?
—
Reply to this email directly, view it on GitHub
<#30 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADKNR4RJEQOTINF6AGZ2QLTU3ASBFANCNFSM5OIC6HHA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I've tested and it doesn't work 100% correctly. The events are duplicated. |
|
This is what I have after opening the second page and sending a single message: Maybe you don't see this in your project because you don't log message like my demo do. |
|
I think that if there are two iframes it breaks. It should work the same with the old setup with having two iframes. So you need to check the domain of the iframe. I used my demo that had two iframes for terminal.jcubic.pl ad jcubic.pl and I used localhost to connect. |
|
I'm also wondering if there is no security issue with your solution. This is done only by a single browser but some applications may send sensitive information and they can leak out. If someone will open a connection without an iframe. |
|
If you really need this, this needs to be protected and restricted to specified Domains only. Domains that are in |
|
|
||
| var key = data && data.name; | ||
| if (callbacks[key]) | ||
| invoke(key, data.data); |
There was a problem hiding this comment.
And please use curly braces on if statements. Maybe I should set up ESLint for this.
|
Just contributing what I already coded. Sorry, but do not plan on
contributing further unless my use case requires it. Was just hoping my
code would help someone else in need of it.
Hector G. Bas III
…On Sun, Feb 13, 2022, 4:56 PM Jakub T. Jankiewicz ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In sysend.js
<#30 (comment)>:
> + // Track when receiving messages from iframes
+ window.addEventListener("message", function(e) {
+ if (typeof e.data === 'string' && e.data.match(prefix_re)) {
+ try {
+ var payload = JSON.parse(e.data);
+ if (!payload || payload.name !== uniq_prefix) return;
+
+ var data = unserialize(payload.data);
+
+ if (data.data && data.data.target && payload.iframe_id && payload.iframe_id == data.data.target) {
+ data.data.target = target_id; // Swap target ID's since this call came from iframe
+ }
+
+ var key = data && data.name;
+ if (callbacks[key])
+ invoke(key, data.data);
And please use curly braces on if statements. Maybe I should set up ESLint
for this.
—
Reply to this email directly, view it on GitHub
<#30 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADKNR4VABISNGSTTBODRYYDU3AZIFANCNFSM5OIC6HHA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
If so I will merge this PR into an experimental branch. And investigate. Right now it doesn't work and break existing code. So it can't land into the master branch unless bugs are fixed. |
|
If you create a PR, you expect it to have no visible bug at least. |
|
Can you change the target branch to |
|
I think that security is not a problem, because even right now attackers can listen to events. |
|
I needed to move development to devel branch because there was some issue with this solution. I thought that it was working but it's not. I have one of two behaviors no message sent or duplicated message. |
2 participants
Pass proxy invoke calls BACK to parent frame with postMessage. Tested for my individual purposes (broadcast, post), so I'd be surprised if any of the events are showing accurately. Really the proxy page needs to point to it's own abstracted JS file that forwards along each request/event correctly, with out all the logic bits (i.e. a router).
Ref #29