ss5 at renormalist
Apr 24, 2008, 2:19 AM
Post #2 of 3
(184 views)
Permalink
|
|
Re: [7927] bug 1267, take away hostname from login URL,
[In reply to]
|
|
"David E. Wheeler" <david[at]kineticode.com> writes:
> On Jun 19, 2007, at 10:02, David E. Wheeler wrote:
>
>> On Jun 19, 2007, at 07:13, slanning[at]bricolage.cc wrote:
>>
>>> - redirect_onload('http://' . $r->hostname . $port . $redir,
>>> $self);
>>> + redirect_onload($redir, $self);
>>
>> I'm not sure about this. There is usually a very good reason that
>> the host name is included. Furthermore, it should not be required
>> for Apache 2 reverse proxying (which I've been using with Bricolage
>> installations for years now) as long as the host name configuration
>> in bricolage.conf resolves to the proxy server and the proxy server
>> knows what server to pass it back to.
>
> Hey,
>
> It turns out that the reason for the above was so that, if
> ALWAY_USE_SSL was false, the user would be redirected to the non-SSL
> port. In testing the Apache 2 port, I discovered that Bricolage was
> always staying in SSL because of this change. So I'm reverting this
> change.
>
> Steffen, if you set ALWAYS_USE_SSL to "Yes", then you should once
> again be able to use Bricolage behind your Apache 2 reverse
> proxy. It turns out that that's why I never had a problem with the
> Kineticode Bricolage behind a reverse proxy: I had ALWAYS_USE_SSL
> set to "Yes". That setting is effectively the same as the above
> patch, as it keeps you in SSL and so only needs to do redirects like
> "/login" instead of "http://localhost/login ". I'll document this.
I'm not sure.
I'm scared of setting ALWAYS_USE_SSL when in fact I want my Bricolage
NEVER_DO_SSL.
That would be morally wrong, besides from that I think that 3 years
ago when I struggled with all that reverse proxy stuff I'm quite sure
I tried "everything"(tm). And there were several other people at that
time reporting that their reverse proxies did not work.
I'm currently not able to test this on our production systems, someone
else is maintaining them. We will see whether it troubles them. It
would make sense to at least keep it how it worked in the rev_1_10
branch.
In my opionion, seeing currently so much refactoring on Bricolage, why
not throw away all that self-doing SSL handling? That SSL handling is
clearly something that belongs to the webserver's competence. Reducing
and distributing complexity is nearly always a Good Thing.
Kind regards,
Steffen
--
Steffen Schwigon <ss5[at]renormalist.net>
Dresden Perl Mongers <http://dresden-pm.org/>
Deutscher Perl-Workshop <http://www.perl-workshop.de/>
|
