Sites using location-bar or similar breaks in unblocker about node-unblocker HOT 11 CLOSED

I can add that I'm making progress on this! :)

from node-unblocker.

Yea, I've thought about adding a subdomain mode a few times. Part of the problem is that it would be much more difficult to test and to set up a private instance, as you then need a proper DNS server. I can set up a *.localhost.nodeunblocker.com DNS entry that always points to localhost to make testing easier, but that doesn't help for users who want to run their own copy. It might still be worth it, but it's a major change to functionality.

It would make cookie processing much simpler.

As for http/https - I think the simple solution is to just make the server support both and match the requested protocol. But again, this makes setup more complex. (Although, if you don't mind a self-signed certificate, I can include one with the project.)

There is an alternate option of injecting JS that wraps pushState - I've been thinking about this to work around land other APIs that affect or depend on the URL. I've been thinking about this to work around login issues that depend on postMessage, so it's worth considering. pushState would probably be easier to wrap than postMessage since it only deals with the path.

from node-unblocker.

A potential fix that's not good but will work in most cases would to make unblocker prepend a script tag with the following.

delete window.history
delete history // It might do it to just do the above.

Since many tools today checks whether window.history or history exists and fall back on hashchange instead it could work for a while until all browsers support popState

from node-unblocker.

Heh, yea, that would probably work too, at least for a little while. Although prettymuch all browsers already support it (http://caniuse.com/#feat=history) so I can certainly imagine sites that just assume it will exist.

I tried that with postMessage, and a lot of stuff was still broken :/

from node-unblocker.

Hehe, tried it and it caused issues of course... :/

I will attempt to make a domain version like I mentioned above. I'll keep you posted.

from node-unblocker.

Cool, sounds good
On Aug 6, 2015 8:09 AM, "Emil Hemdal" [email protected] wrote:

Hehe, tried it and it caused issues of course... :/

I will attempt to make a domain version like I mentioned above. I'll keep
you posted.

—
Reply to this email directly or view it on GitHub
#47 (comment)
.

from node-unblocker.

I'm making great progress!

Should I make a pull request with the change as an option in config when I've tested it more?

from node-unblocker.

Yea, please do
On Aug 7, 2015 4:43 AM, "Emil Hemdal" [email protected] wrote:

I'm making great progress!

Should I make a pull request with the change as an option in config when
I've tested it more?

—
Reply to this email directly or view it on GitHub
#47 (comment)
.

from node-unblocker.

Almost a year later... I've partially stopped working on the company where I develop this and I will quit in the middle of august. I'm working until then 100% on the proxy. I have pushed some changes that I made a long time ago with some tests to my fork.

from node-unblocker.

Awesome, and no worries about the delay. I'm at work right now but I'll
check out your stuff and respond as time allows.

from node-unblocker.

I know this is a super-old ticket, but I fixed this issue in v2.3.0 in the process of trying to make youtube work.

The proxy now injects some JavaScript that wraps history.pushState() and history.replaceState() to fixup the URLs before passing the call along to the browser.

So if the website's code calls

history.pushState({}, 'title', '/foo/bar')

the proxy code will intercept that and rewrite it to

history.pushState({}, 'title', '/proxy/foo/bar')

(or whatever you have prefix configured to)

from node-unblocker.