Skip to content

Is proxy support (almost) gone?Β #354

Closed

Description

@uschwarz

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.)

Activity

  1. iparamonau commented on Feb 22, 2022

    @iparamonau
    Member

    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.

  2. nleush commented on Feb 22, 2022

    @nleush
    Member

    @uschwarz Here’s the sample proxy/echo service for Iframely to use with CONFIG.PROXY_URL: https://gist.github.com/nleush/7916ee89f7b8d6f0cd478d7335702139

  3. added a commit that references this issue on Feb 22, 2022
  4. iparamonau commented on Feb 23, 2022

    @iparamonau
    Member

    It looks like this now should be resolved. Feel free to reopen.

  5. uschwarz commented on Mar 1, 2022

    @uschwarz
    Author

    FWIW, I'm reasonably confident you can achieve forwarding through Apache httpd config alone, along the lines of

    ProxyRemote "*" http://mysquid.server
    SSLProxyEngine on
    
    RewriteEngine on
    RewriteMap unescape int:unescape
    RewriteCond "%{QUERY_STRING}" "url=(.*)"
    RewriteRule ^ ${unescape:%1} [P,noescape]
    

    if you already had a working setup with Squid (or any other proxy server of your choice).

  6. uschwarz commented on Aug 24, 2022

    @uschwarz
    Author

    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.

  7. uschwarz commented on Aug 25, 2022

    @uschwarz
    Author

    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.)

  8. iparamonau commented on Aug 25, 2022

    @iparamonau
    Member

    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.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions