You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Jörn Nettingsmeier <ne...@apache.org> on 2007/05/07 00:17:10 UTC
problems?
hi everyone!
i'm playing around with proxying since i need to get a lenya site out
and i figured it could use some testing before the release.
proxying the live site works nicely, but ssl-proxying the authoring area
does not work at all.
in my apache virtual host configuration, i do this:
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://localhost:8888/mypub/live/
ProxyPassReverse / http://localhost:8888/mypub/live/
as you can see, i'm using a jetty on localhost and an apache on the outside.
works like a charm.
the pain starts when using ssl: as you may know, it is not possible to
have name-based virtual ssl hosts, because you can only have one ssl
certificate and alternative vhost names would not match the server name
in that certificate. so i need to redirect all publications to my
default ssl server:
<VirtualHost "88.198.247.82:443">
...
SSLEngine on
...
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /cms/mypub/ http://localhost:8888/mypub/authoring/
ProxyPassReverse /cms/mypub/ http://localhost:8888/mypub/authoring/
</VirtualHost>
as you see, sub-directories come into play.
my lenya publication is configured as follows:
<proxies>
<proxy area="live" ssl="true" url="https://mypub.com/"/>
<proxy area="live" ssl="false" url="http://mypub.com/"/>
<proxy area="authoring" ssl="true"
url="https://mysslserver.net/cms/mypub/"/>
<proxy area="authoring" ssl="false"
url="http://mysslserver.net/cms/mypub/"/>
</proxies>
now when i request a page from authoring by pointing my browser at
https://mysslserver.net/cms/mypub/, i get a login usecase, but no
styling at all. after logging in, i get a text-only version of the lenya
gui.
interestingly, stuff goes wrong in several different ways:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Apache Lenya | fairsolution | authoring | /index.html |
Home</title>
<script src="/lenya/menu/menu.js" type="text/javascript"> </script>
<link href="/lenya/css/menu.css" rel="stylesheet" type="text/css" />
<link rel="icon" href="/favicon.ico" type="image/ico" />
gui-specific links do not take the proxy settings into account.
<link
href="http://mysslserver.net/cms/mypub//index/introspection.xml"
type="application/neutron+xml" rel="neutron-introspection" />
<link type="text/css"
href="http://stackingdwarves.net/cms/fairsolution//css/fair-solution.css"
rel="stylesheet" />
<link type="text/css"
href="http://stackingdwarves.net/cms/fairsolution//css/xhtml.css"
rel="stylesheet" />
these links almost work, except for the protocol (should be https, my
server does not serve that content on port 80 unencrypted). seems
related to a bug reported by richard:
http://issues.apache.org/bugzilla/show_bug.cgi?id=42050
<...>
<div id="sidebar">
<ul id="nav">
<li>
<a class="active" href="index.html">Home</a>
</li>
<li>
<a href="unternehmen.html">Unternehmen</a>
</li>
<li>
<a href="leistungen.html">Leistungen</a>
</li>
<li>
<a href="projekte.html">Projekte</a>
</li>
<li>
<a href="kontakt.html">Kontakt</a>
</li>
</ul>
this is the lenya-generated navigation. it seems to be totally oblivious
to the proxy settings.
before i hit bugzilla: how is proxying supposed to work? am i making
obvious configuration mistakes or do i demand stuff it wasn't designed for?
before you ask: yes, all the reported problems can be reproduced with
the default publication.
any comments appreciated.
regards,
jörn
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: problems?
Posted by Andreas Hartmann <an...@apache.org>.
Joern Nettingsmeier schrieb:
> drat. i just read the BaseURLModule, and it looks like proxies will only
> work if every single fscking lenya component uses that module... why oh
> why?
>
> what is the advantage of hauling around proxy objects for every single
> page and requiring to code proxy awareness into every sitemap? why don't
> we just toss in a global link rewriter that will take care of it all?
I'm not sure if it's that easy. Some people want to protect the whole
site, some only single pages, some only the login usecase.
> can anyone enlighten me what the design goals are?
I'm not sure either. The only thing I know is that the SSL checkbox
is used to configure the pages which should require SSL, and that
the ProxyUrlModule can determine the URLs accordingly.
> currently i don't
> know how to approach this issue...
> the most obvious solution would be to rip all existing proxy support out
> and add it to the existing link rewriter. but surely there must be a
> reason why it is not done?
I'm not sure if there is a reason.
> i see how this will cause problems if people rely on the per-page ssl
> checkbox, but imho that is quite a corner case. it's far more important
> to be able to ssl-encrypt access to the authoring area easily and to be
> able to protect some usecases...
OK, I'd be interested in a proposal (see my mail "SSL handling").
Thanks for your comments,
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: problems?
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
drat. i just read the BaseURLModule, and it looks like proxies will only
work if every single fscking lenya component uses that module... why oh why?
what is the advantage of hauling around proxy objects for every single
page and requiring to code proxy awareness into every sitemap? why don't
we just toss in a global link rewriter that will take care of it all?
can anyone enlighten me what the design goals are? currently i don't
know how to approach this issue...
the most obvious solution would be to rip all existing proxy support out
and add it to the existing link rewriter. but surely there must be a
reason why it is not done?
i see how this will cause problems if people rely on the per-page ssl
checkbox, but imho that is quite a corner case. it's far more important
to be able to ssl-encrypt access to the authoring area easily and to be
able to protect some usecases...
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: problems?
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>> Jörn Nettingsmeier schrieb:
>>
>> [...]
>>
>>> the pain starts when using ssl:
>>> <script src="/lenya/menu/menu.js" type="text/javascript"> </script>
>>
>> I noticed that the "ssl" parameter wasn't passed to the base URL module.
>> I added the attribute to the access-control module and to the default
>> publication sitemap.
>>
>> Would you mind updating your sitemap and trying it again? TIA!
>
> no change.
>
> i don't understand: what does the ssl parameter have to do with it?
> isn't that the checkbox in the ac live/ac authoring tab?
Yes.
> iiuc, all absolute links should be rewritten if a proxy is defined, and
> it should happen in the link transformer at the very end...
OK. ATM, configuring SSL is per page.
> anyways, requiring an extra parameter to be added to the sitemap in
> several places doesn't seem like a good solution to me.
>
> is anyone familiar with the original design goal of <proxy/>? is it
> supposed to work only for hostnames, or can i use sub-directories as well?
It's just a string which links will start with. You can use whatever
you want.
> can you explain what the ssl checkbox is meant for?
It is used to define which pages should use SSL encryption.
But I'm not sure about the places which it is used.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: problems?
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier schrieb:
>
> [...]
>
>> the pain starts when using ssl:
>> <script src="/lenya/menu/menu.js" type="text/javascript"> </script>
>
> I noticed that the "ssl" parameter wasn't passed to the base URL module.
> I added the attribute to the access-control module and to the default
> publication sitemap.
>
> Would you mind updating your sitemap and trying it again? TIA!
no change.
i don't understand: what does the ssl parameter have to do with it?
isn't that the checkbox in the ac live/ac authoring tab?
iiuc, all absolute links should be rewritten if a proxy is defined, and
it should happen in the link transformer at the very end...
anyways, requiring an extra parameter to be added to the sitemap in
several places doesn't seem like a good solution to me.
is anyone familiar with the original design goal of <proxy/>? is it
supposed to work only for hostnames, or can i use sub-directories as well?
can you explain what the ssl checkbox is meant for?
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: problems?
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
[...]
> the pain starts when using ssl:
> <script src="/lenya/menu/menu.js" type="text/javascript"> </script>
I noticed that the "ssl" parameter wasn't passed to the base URL module.
I added the attribute to the access-control module and to the default
publication sitemap.
Would you mind updating your sitemap and trying it again? TIA!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: problems?
Posted by Markus Angst <ma...@inventec.ch>.
Jörn Nettingsmeier wrote:
> Markus Angst wrote:
>> Hi Jörn,
>>
>> > ...
>>> the pain starts when using ssl: as you may know, it is not possible to
>>> have name-based virtual ssl hosts, because you can only have one ssl
>>> certificate and alternative vhost names would not match the server
>>> name in that certificate.
>>
>> Yes, that's what the Apache documentation says. Not sure if this is
>> true... We are running Apache 2.2.4 and the following works on our
>> development machines (sorry it's a bit lenghty):
>
> i think it will only work if you do not care about security (i.e.
> educate your users to click away any bogus certificate warnings).
Of course I don't want to do that. My browser always gives me a warning when the
domain of a certificate does not match the domain of the server. When using the
setting I posted, there is no such warning and when I view the certificates in
the browser they match correctly.
> here's an explanation:
> http://fob.po8.org/node/284
Sounds reasonable.
> iiuc, working around this issue would require a certificate
> re-negotiation, which implies an extension of HTTP 1.1.
I investigated a little and found out, what is probably going on on my side...
The entries for my local machine in my hosts file look like this:
127.0.0.1 localhost
127.0.0.1 www.mypub.dev
192.168.186.2 pc2
So the two vhosts/certificates are in fact attached to two different IP numbers
(indirectly via dns lookup)... Mystery solved. Sorry for the noise.
Thanks!
Markus Angst
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: problems?
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Markus Angst wrote:
> Hi Jörn,
>
> > ...
>> the pain starts when using ssl: as you may know, it is not possible to
>> have name-based virtual ssl hosts, because you can only have one ssl
>> certificate and alternative vhost names would not match the server
>> name in that certificate.
>
> Yes, that's what the Apache documentation says. Not sure if this is
> true... We are running Apache 2.2.4 and the following works on our
> development machines (sorry it's a bit lenghty):
i think it will only work if you do not care about security (i.e.
educate your users to click away any bogus certificate warnings).
here's an explanation:
http://fob.po8.org/node/284
iiuc, working around this issue would require a certificate
re-negotiation, which implies an extension of HTTP 1.1.
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: problems?
Posted by Markus Angst <ma...@inventec.ch>.
Hi Jörn,
> ...
> the pain starts when using ssl: as you may know, it is not possible to
> have name-based virtual ssl hosts, because you can only have one ssl
> certificate and alternative vhost names would not match the server name
> in that certificate.
Yes, that's what the Apache documentation says. Not sure if this is true... We
are running Apache 2.2.4 and the following works on our development machines
(sorry it's a bit lenghty):
ProxyRequests Off
<VirtualHost _default_:443>
ServerName pc2.inventec.ch:443
ServerAdmin mangst@inventec.ch
DocumentRoot "C:/inetpub/wwwroot"
SSLEngine on
SSLCertificateFile "conf/server.crt"
SSLCertificateKeyFile "conf/server.key"
...
</VirtualHost>
...
NameVirtualHost www.mypub.dev:80
<VirtualHost www.mypub.dev:80>
ServerName www.mypub.dev
ServerAdmin webmaster@www.mypub.dev
DocumentRoot "C:/htdocs/mypub"
Options -Indexes
RewriteEngine On
#redirect shop to https (VH for https below will handle the request)
RewriteRule ^/shop$
https://www.mypub.dev/shop/shops/allgemein/scripts/main.php?g_cid=1 [R,L]
RewriteRule ^/shop(.*) https://www.mypub.dev/shop/$1 [L]
#redirect /edit to https authoring
RewriteRule ^/(.*)/edit$ https://www.mypub.dev/mypub/authoring/$1 [R,L]
RewriteRule ^/edit https://www.mypub.dev/mypub/authoring/index.html [R,L]
RewriteRule ^/$ index.html [P]
# the following rule cuts off /mypub/live and redirects
RewriteRule ^/mypub/live/(.*)$ $1 [R,L]
# lenya wide resources
RewriteRule ^/lenya/?(.*) http://www.mypub.dev:8888/lenya/$1 [P]
# modules
RewriteRule ^/modules/?(.*) http://www.mypub.dev:8888/modules/$1 [P]
# mypub wide resources
RewriteRule ^/mypub/?(.*) http://www.mypub.dev:8888/mypub/$1 [P]
# exclude the shop (probably the rule will never match (rule above)
RewriteCond %{REQUEST_URI} !^/shop(.*)$
RewriteRule ^/(.*) http://www.mypub.dev:8888/mypub/live/$1 [P]
ProxyPassReverse / http://www.mypub.dev:8888/
</VirtualHost>
NameVirtualHost www.mypub.dev:443
<VirtualHost www.mypub.dev:443>
ServerName www.mypub.dev
ServerAdmin webmaster@www.mypub.dev
DocumentRoot "C:/htdocs/mypub"
Options -Indexes
RewriteEngine On
SSLEngine On
SSLCertificateFile "conf/mypub-dev.crt"
SSLCertificateKeyFile "conf/mypub-dev.key"
# lenya wide resources
RewriteRule ^/lenya/?(.*) http://www.mypub.dev:8888/lenya/$1 [P]
# modules
RewriteRule ^/modules/?(.*) http://www.mypub.dev:8888/modules/$1 [P]
# mypub wide resources
RewriteRule ^/mypub/?(.*) http://www.mypub.dev:8888/mypub/$1 [P]
# cut off /mypub/live for encrypted live pages and redirect
# (last rule before proxpassreverse will match)
RewriteRule ^/mypub/live/(.*) $1 [R,L]
RewriteRule ^/mypub/authoring/(.*)
http://www.mypub.dev:8888/mypub/authoring/$1 [P]
# exclude the shop
RewriteCond %{REQUEST_URI} !^/shop(.*)$
RewriteRule ^/(.*) http://www.mypub.dev:8888/mypub/live/$1 [P]
ProxyPassReverse / http://www.mypub.dev:8888/
</VirtualHost>
We haven't set any Lenya proxy settings. They don't seem to be necessary in our
environment. Besides Lenya, we have a shop that is written in PHP and is tightly
integrated with the Lenya publication by some of the rewrite rules above and a
tab in the navigation.
Note that there are two different (self-signed) certificates with matching names
in two different virtual hosts. Note also that this setting is a work in
progress and has not yet been used in a productive environment.
Hope this helps,
Markus Angst
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org