Thank you guys for such a quick response and elaborated answers. I haved
turned on the browser's debug tool and what i can get from there is
"Status": 401 unauthorized for many resources.
As per setting cookies I havent try any of this, dont know how to at the
moment. here is the configuration I have in my vhost file:
ProxyRequests Off
ProxyPreserveHost Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /innerLink/ http://intrasrv01:8080/sites/Home.aspx
ProxyPassReverse /innerLink/ http://intrasrv01:8080/sites/Home.aspx
ProxyPass / http://intrasrv01:8080/
ProxyPassReverse / http://intrasrv01:8080/
RequestHeader unset Accept-Encoding
AddOutputFilterByType SUBSTITUTE text/html
Substitute "s|http://intrasrv01:8080/|http://172.16.27.7:8080/|ni"
the site is in a sharepoint 2010 server. The new odd thing is
happening is that sometimes loads almost all resources with just one
login, and some times is prompting for ever
On Tue, Mar 24, 2020 at 8:28 PM Muggeridge, Matt <matt.muggerid...@hpe.com>
wrote:
> I’ll add a little more about cookies to Mark’s excellent answer…
>
>
>
> If you’re using cookies for passing authentication tokens via the
> reverse-proxy, then read about ProxyPassReverseCookiePath.
>
>
>
> E.g. let’s say your proxy uses the path “/foo/” and this is mapped to ”/” on
> the backend. Then you need a line in your configuration file:
>
>
>
> ProxyPassReverseCookiePath / /foo/
>
>
>
> COOKIES and REVERSE PROXY:
>
> - Client issues a login request.
>
> - The backend server responds to the login request with a "Set-Cookie"
> header containing the cookie value and "path=/".
>
> - The reverse proxy must map the path to match the request, so "path=/"
> must be rewritten as "path=/<proxy-request-path>/".
>
>
>
> NOTE: You can see what’s needed by tracing the Cookie content on the
> backend server as well as this proxy. E.g. tracing the Set-Cookie in the
> Proxy might require something like:
>
>
>
> LogFormat "%h %l %u %t \"%r\" \"%{Content-Type}o\" \"C:%{Cookie}i\"
> \"S-C:%{Set-Cookie}o\" %>s %b"
>
> TransferLog "/store/log/httpd_access_log"
>
>
>
> Matt.
>
>
>
>
>
> *From:* Mark Brodis <mabro...@colorado4x4.net>
> *Sent:* Wednesday, 25 March 2020 1:58 AM
> *To:* users@httpd.apache.org
> *Subject:* Re: [users@httpd] Reverse proxy
>
>
>
> Without knowing exactly how your setup is configured, my guess is the
> issue is that when you authenticate the first time to the remote site
> whatever auth logic it's using that is not being persistent for your
> connection or repeat requests. Typically this would be a cookie, you
> authenticate successfully, the site gives you a cookie with some session ID
> in it, with each request you send that cookie and it references a valid
> session so it does not make you re-authenticate. That cookie from the site
> could be set with specific parameters, what hosts or domains are valid for
> it (when should the browser send this cookie with requests to those
> hosts/domains), what it can be used for (HTTPonly is common), expiration
> date, whether the browser should only send the cookie for secure
> connections, etc.
>
>
>
> My guess is whatever that logic is, it's not getting back to the browser
> so the browser either doesn't have, or isn't sending, whatever the site
> wants to see to show that you already have a valid session.
>
>
>
> Commonly this could happen if you are accessing a site by a different
> name, if you access 'coolsite.example.com' and that hits your proxy, ends
> up fetching content from 'othersite.foo.org', then whatever cookies the '
> othersite.foo.org' site puts in the response, they should make it back to
> the originating browser (will be in the response header), but they will be
> for 'othersite.foo.org' and your browser will reject them because they
> will come in a reponse to a request for 'coolsite.example.com', if your
> browser did save them it still wouldn't use them for the next request
> because the name on them would be for 'othersite.foo.org' so it would
> dutifully only send those cookies to requests to that site (which you
> wouldn't be doing, you'd be going to 'coolsite.example.com').
>
>
>
> If you turn on debugging (all modern browsers have this) or use a HTTP
> capture local proxy (if running Windows then Fiddler Tool is very good) you
> can see these transactions happen and see exactly what was sent and
> received from the browser's perspective.
>
>
>
> That's how I would start debugging at least.
>
>
>
> If that is the problem..then how to fix that (which is pseudo faking out
> the browser) would be to rewrite/modify the 'set-cookie' command as it
> comes from the remote server in the response and change the host/domain
> value in it to match what you actually went to. I believe that can be done
> as part of mod_rewrite but I don't have a lot of experience doing that.
>
>
>
> Good luck.
>
>
>
> On Tue, Mar 24, 2020 at 7:19 AM Jairo Jimenez <jairo.xime...@gmail.com>
> wrote:
>
> Greetings I am new to apache. so please dont be so hard if this is too
> basic
>
>
>
> I;ve been practicing by my self looking for scenarios to solve, but I have
> this a particular one that I can[t figure out.
>
>
>
> I manage to set some sore of reverse proxy to forward a website that I
> have on an intranet.(forward it to external net throug VPN).
>
>
>
> The thing I cant figure out is that when I acces this site through the
> proxy, it prompts to enter the user name an pass but it is doing this for
> every resource that needs to download, eg: images, style sheets,scripts
> every thing.
>
>
>
> Is there a way I can configure apache confs to manage this and store some
> kind of cookie or cache to avoid this and enter login credentials just
> once.?
>
>
