You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears 2.0.0 only uses the proxy settings for loading the go-list (that seems to still use the old requests lib), not for the actual requests anymore. I see no hits on the proxy and no matter how loose I make the regex, requests are made directly.
I couldn't find mention of proxy support in helix-fetch, so is the possibility of having proxy settings by regex matching against the URI gone for good? (Our use case was to route requests for on-site resources through an off-site proxy as an extra safeguard against exposing intranets etc.)
Basically, that is a one-liner app that fetches the URL and pipes it to Iframely instance. Configured as CONFIG.PROXY_URL. Let me know if you'd the code for that app, we'll include the gist.
Sorry for the late followup, but of course things only bite you in productionβ¦
Passing everything through this kind of proxy service means the fetched page can't usefully inspect its own window.location anymore (it sees the proxy service's), relative links break, and all these pages probably now have the same Origin, which has privacy and possibly security implications.
I take that back, I was getting confused in the layers of redirection. (I still think "have an URL endpoint that does it" is the inferior solution, but there's not much we can do as long as adobe helix disagrees.)
Well we could always implement proxies w/o heilix-fetch, for example by keeping request for such URLs. But we won't be doing it ourselves because in fact we like current solution better than actual proxies. It works for our purposes very well. HTML on the page is all we need.
Activity
iparamonau commentedon Feb 22, 2022
Thanks, we missed that. Indeed, there's no built-in proxy support via HTTP headers now. We ourselves use a simple echo instead:
https://github.com/itteco/iframely/blob/master/lib/utils.js#L82-L84
Basically, that is a one-liner app that fetches the URL and pipes it to Iframely instance. Configured as
CONFIG.PROXY_URL. Let me know if you'd the code for that app, we'll include the gist.nleush commentedon Feb 22, 2022
@uschwarz Hereβs the sample proxy/echo service for
Iframelyto use withCONFIG.PROXY_URL: https://gist.github.com/nleush/7916ee89f7b8d6f0cd478d7335702139add `PROXY_URL` to example config
iparamonau commentedon Feb 23, 2022
It looks like this now should be resolved. Feel free to reopen.
uschwarz commentedon Mar 1, 2022
FWIW, I'm reasonably confident you can achieve forwarding through Apache httpd config alone, along the lines of
if you already had a working setup with Squid (or any other proxy server of your choice).
uschwarz commentedon Aug 24, 2022
Sorry for the late followup, but of course things only bite you in productionβ¦
Passing everything through this kind of proxy service means the fetched page can't usefully inspect its own window.location anymore (it sees the proxy service's), relative links break, and all these pages probably now have the same Origin, which has privacy and possibly security implications.
uschwarz commentedon Aug 25, 2022
I take that back, I was getting confused in the layers of redirection. (I still think "have an URL endpoint that does it" is the inferior solution, but there's not much we can do as long as adobe helix disagrees.)
iparamonau commentedon Aug 25, 2022
Well we could always implement proxies w/o
heilix-fetch, for example by keepingrequestfor such URLs. But we won't be doing it ourselves because in fact we like current solution better than actual proxies. It works for our purposes very well. HTML on the page is all we need.