You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/09/20 10:41:10 UTC
Protocol switch in portals (was Re: furious anger: portal broken)
Ralph Goers wrote:
>
> Sylvain Wallez wrote:
>
>>> Ok, that's it on *that* subject (I hope), let's get into the
>>> technical discussion:
>>>
>>> Both, the JSR 168 and WSRP require the functionality to switch from
>>> http to https and back. Switching the protocol is only possible with
>>> absolute urls (for the switch itself). That's the reason why the
>>> LinkService now creates absolute urls.
>>>
>>
>>
>> Can you elaborate on this protocol switch? What is it about? Any
>> pointers?
>>
>>
> Very often you want to display a few pages, but not all, of your
> website using SSL. So you use http for most of the website but use
> https for the few pages that need it. That necessitates using the
> absolute path since the switch from http to https isn't relative to
> anything.
I'm a total newbie on this matter, so that may be dumb questions. I
don't see how absolutizing links allows this: the result of
absolutization is that all links use the protocol that was used by the
current request, i.e. if it's http than all links will use http and if
it's https then all links will use https.
It seems to me that the protocol to be used depends on the page that is
to be displayed rather than where you come from to that page, no?
Absolutization means that once you enter the site using a particular
protocol, you always use that one. Or did I missed something?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Absolutizing with request.getServerName() (was: Protocol switch...)
Posted by BURGHARD Éric <er...@systheo.com>.
Bertrand Delacretaz wrote:
> Le 21 sept. 05, à 14:04, BURGHARD Éric a écrit :
>> ....If i understand correctly, the request.getServerName() is not
>> useable for
>> absolutisation since it names the server in his local environnement..
>
> Did you follow Vadim's advice earlier in this thread?
>
> Le 19 sept. 05, à 14:45, Vadim Gritsenko a écrit :
>> ...Use ProxyPreserveHost
>>
>> http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypreservehost
>
> I think request.getServerName() should return the correct value then.
>
Yes but for me it's going to far in virtual host or http server
configuration and it's tied to a particular http server configuration.
getServerName() apparently
"Returns the host name of the server that received the request"
which not what you want i guess.
getHeader('Host') is preferable as it returns the name that appears in the
client's browser.
for me a prefix constructed from sitemap with
<map:parameter name="site"
value="{request:scheme}://{request-header:Host}/{request:contextPath}"/>
seems to work well to absolutize my urls (i'm using apache+tomcat5).
Regards.
Absolutizing with request.getServerName() (was: Protocol switch...)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 21 sept. 05, à 14:04, BURGHARD Éric a écrit :
> ....If i understand correctly, the request.getServerName() is not
> useable for
> absolutisation since it names the server in his local environnement..
Did you follow Vadim's advice earlier in this thread?
Le 19 sept. 05, à 14:45, Vadim Gritsenko a écrit :
> ...Use ProxyPreserveHost
>
> http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypreservehost
I think request.getServerName() should return the correct value then.
-Bertrand
Re: Protocol switch in portals
Posted by Carsten Ziegeler <cz...@apache.org>.
I'll commit an improved version today that will only use absolute urls
if the protocol is switched. If the protocol stays the same, the url
will be relative - as in 2.1.7.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Protocol switch in portals (was Re: furious anger: portal broken)
Posted by BURGHARD Éric <er...@systheo.com>.
Bertrand Delacretaz wrote:
> Le 20 sept. 05, à 10:57, Carsten Ziegeler a écrit :
>> ...The LinkService accepts a boolean argument indicating if you want a
>> secure link. If this is set to true then the service switches to https.
>> As I said yesterday, we could create relative links if the procotol is
>> not changed, but there are cases where we need absolute links...
>
> There are other use-cases for absolutizing links: in one of my projects
> we're sending a newsletter as an HTML email (only to users who want it
> ;-) and in such a case you need to absolutize all links in the
> generated email so that the mail client gets correct URLs. The brute
> force way is to configure the base absolute URL somewhere, but a
> general mechanism might be useful.
>
Yes, this is exactly what i'm trying to do, and found that thread while
looking for a way to solve this problem (as i found bertrand's blog about
MailTransformer :-).
If i understand correctly, the request.getServerName() is not useable for
absolutisation since it names the server in his local environnement
(doesn't follow virtual host name for example). I don't really see the use
of such method in the request object where you are more interrested by the
request than the local network environnment.
Perhaps the solution is just to replace the request.getServerName() and
getServerPort() by the value retrieved from the 'Host' request header
attribute which contain normally both.
Regards.
Re: Protocol switch in portals (was Re: furious anger: portal broken)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 20 sept. 05, à 10:57, Carsten Ziegeler a écrit :
> ...The LinkService accepts a boolean argument indicating if you want a
> secure link. If this is set to true then the service switches to https.
> As I said yesterday, we could create relative links if the procotol is
> not changed, but there are cases where we need absolute links...
There are other use-cases for absolutizing links: in one of my projects
we're sending a newsletter as an HTML email (only to users who want it
;-) and in such a case you need to absolutize all links in the
generated email so that the mail client gets correct URLs. The brute
force way is to configure the base absolute URL somewhere, but a
general mechanism might be useful.
Dunno if this is helps in this discussion, just wanted to point out
that this http/https thing is not the only need for absolute links.
-Bertrand
Re: Protocol switch in portals
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain,
If I recall correctly when switching back to http from https the link
also has to be absolute.
Ralph
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Yes, I already agreed to this - so someone just has to implement it
>> which shouldn't be that hard.
>>
>>
>
> Ok, I'll do it.
>
> Sylvain
>
Re: Protocol switch in portals
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Right. Now projects that use Cocoon as a complete solution don't really
>>care about jsr168 and WSRP!
>>
>>
>
>Everyone is free to use what he wants :) I think using standardized
>portlets helps a lot in some cases.
>
>
C'mon, I never said the contrary, but just that people using Cocoon and
only Cocoon should not be bothered by jsr168 or wsrp-related problems.
>>So, restating my question as I'd really like to know, what are the use
>>cases that require URL absolutization other than when a coplet/portlet
>>wants to enforce the protocol?
>>
>>This is because we could avoid absolutizing except when the portlet ask
>>for a particular protocol, i.e. the Boolean parameter in getLinkURI() is
>>not null.
>>
>>
>Yes, I already agreed to this - so someone just has to implement it
>which shouldn't be that hard.
>
>
Ok, I'll do it.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Protocol switch in portals
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> Right. Now projects that use Cocoon as a complete solution don't really
> care about jsr168 and WSRP!
Everyone is free to use what he wants :) I think using standardized
portlets helps a lot in some cases.
>
> So, restating my question as I'd really like to know, what are the use
> cases that require URL absolutization other than when a coplet/portlet
> wants to enforce the protocol?
>
> This is because we could avoid absolutizing except when the portlet ask
> for a particular protocol, i.e. the Boolean parameter in getLinkURI() is
> not null.
>
Yes, I already agreed to this - so someone just has to implement it
which shouldn't be that hard.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Protocol switch in portals
Posted by Sylvain Wallez <sy...@apache.org>.
Ralph Goers wrote:
> Sylvain Wallez wrote:
>
>>
>> You're right: a working getServerName() is actually needed as soon as
>> we want to switch protocols. But that only happens on sites mixing
>> http and https for urls served by Cocoon, which isn't always the case.
>
>
> You'd be surprised how often you need this! Obviously, you need it
> for something like the petstore where you place an order, but you need
> it for almost any form that has data that might be considered
> "sensitive", i.e. it has account numbers, social security numbers,
> passwords, etc. In fact, the login page really should be secure but
> then you want to switch to http for the majority of a site.
Hmm... but if you switch to http after having authenticated through
https, then the session-id can be hijacked, thus allowing access to the
sensitive data.
>>
>> Sorry: what do you mean by "current protocol" and "protocol request"?
>> I guess it's "the protocol of the current request" and "the protocol
>> asked for by the caller of getLinkURI()"?
>>
>> That should be something like:
>> String proto;
>> if (secure == null) {
>> proto = request.scheme();
>> } else {
>> proto = secure.booleanValue() ? "https" : "http";
>> }
>>
>> if (proto.equals(request.getScheme()) {
>> // same scheme: do not absolutize
>> } else {
>> // different scheme: absolutize
>> }
>>
>> This actually filters more cases where absolutizing will effectively
>> happen, which I like :-)
>
>
> Yes, this looks like what is needed.
Great!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Protocol switch in portals
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
>
> You're right: a working getServerName() is actually needed as soon as
> we want to switch protocols. But that only happens on sites mixing
> http and https for urls served by Cocoon, which isn't always the case.
You'd be surprised how often you need this! Obviously, you need it for
something like the petstore where you place an order, but you need it
for almost any form that has data that might be considered "sensitive",
i.e. it has account numbers, social security numbers, passwords, etc.
In fact, the login page really should be secure but then you want to
switch to http for the majority of a site.
>
> Sorry: what do you mean by "current protocol" and "protocol request"?
> I guess it's "the protocol of the current request" and "the protocol
> asked for by the caller of getLinkURI()"?
>
> That should be something like:
> String proto;
> if (secure == null) {
> proto = request.scheme();
> } else {
> proto = secure.booleanValue() ? "https" : "http";
> }
>
> if (proto.equals(request.getScheme()) {
> // same scheme: do not absolutize
> } else {
> // different scheme: absolutize
> }
>
> This actually filters more cases where absolutizing will effectively
> happen, which I like :-)
>
> Sylvain
Yes, this looks like what is needed.
Ralph
Re: Protocol switch in portals
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>You got me wrong: I haven't said that we should not care about jsr168
>>and wsrp, but that people that don't use it should not be asked to take
>>care about deployment issues (ProxyPreserveHost et al) that are
>>specifically related to these features.
>>
>>
>>
>As soon as you want to switch to https for any forms in your portlets
>you need it, for example if you use cforms to build them.
>
>
You're right: a working getServerName() is actually needed as soon as we
want to switch protocols. But that only happens on sites mixing http and
https for urls served by Cocoon, which isn't always the case.
>>In DefaultLinkService.getInfo() : add a "Boolean secure" parameter and then
>> if (secure != null) {
>> // absolutize using either http or https depending on the value of
>>"secure"
>> } else {
>> // do not absolutize
>> }
>>
>>Isn't it just what is needed?
>>
>>
>
>Hmm, I'm not sure - I think we should compare the current protocol with
>the protocol request and if they're not equal use absolute urls, no?
>
>
Sorry: what do you mean by "current protocol" and "protocol request"? I
guess it's "the protocol of the current request" and "the protocol asked
for by the caller of getLinkURI()"?
That should be something like:
String proto;
if (secure == null) {
proto = request.scheme();
} else {
proto = secure.booleanValue() ? "https" : "http";
}
if (proto.equals(request.getScheme()) {
// same scheme: do not absolutize
} else {
// different scheme: absolutize
}
This actually filters more cases where absolutizing will effectively
happen, which I like :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Protocol switch in portals
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> You got me wrong: I haven't said that we should not care about jsr168
> and wsrp, but that people that don't use it should not be asked to take
> care about deployment issues (ProxyPreserveHost et al) that are
> specifically related to these features.
>
As soon as you want to switch to https for any forms in your portlets
you need it, for example if you use cforms to build them.
>
> In DefaultLinkService.getInfo() : add a "Boolean secure" parameter and then
> if (secure != null) {
> // absolutize using either http or https depending on the value of
> "secure"
> } else {
> // do not absolutize
> }
>
> Isn't it just what is needed?
>
Hmm, I'm not sure - I think we should compare the current protocol with
the protocol request and if they're not equal use absolute urls, no?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Protocol switch in portals
Posted by Sylvain Wallez <sy...@apache.org>.
Ralph Goers wrote:
>
> Sylvain Wallez wrote:
>
>>
>> Right. Now projects that use Cocoon as a complete solution don't
>> really care about jsr168 and WSRP!
>
>
> You're joking right? Our plans are to use the portal for generating
> the site navigation for all our various products since it is perfect
> for that. The fact that it allows JSR-168 portlets to easily
> integrate into that mix is a huge plus as we can get portlets from our
> partners or third party vendors and easily add them to websites.
You got me wrong: I haven't said that we should not care about jsr168
and wsrp, but that people that don't use it should not be asked to take
care about deployment issues (ProxyPreserveHost et al) that are
specifically related to these features.
>>
>> So, restating my question as I'd really like to know, what are the
>> use cases that require URL absolutization other than when a
>> coplet/portlet wants to enforce the protocol?
>>
>> This is because we could avoid absolutizing except when the portlet
>> ask for a particular protocol, i.e. the Boolean parameter in
>> getLinkURI() is not null.
>
>
> As Carsten said, what you are suggesting can be done, but if it was
> that easy I'm sure it would have been done that way in the first place :-)
In DefaultLinkService.getInfo() : add a "Boolean secure" parameter and then
if (secure != null) {
// absolutize using either http or https depending on the value of
"secure"
} else {
// do not absolutize
}
Isn't it just what is needed?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Protocol switch in portals
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
>
> Right. Now projects that use Cocoon as a complete solution don't
> really care about jsr168 and WSRP!
You're joking right? Our plans are to use the portal for generating the
site navigation for all our various products since it is perfect for
that. The fact that it allows JSR-168 portlets to easily integrate into
that mix is a huge plus as we can get portlets from our partners or
third party vendors and easily add them to websites.
>
> So, restating my question as I'd really like to know, what are the use
> cases that require URL absolutization other than when a coplet/portlet
> wants to enforce the protocol?
>
> This is because we could avoid absolutizing except when the portlet
> ask for a particular protocol, i.e. the Boolean parameter in
> getLinkURI() is not null.
>
> Sylvain
As Carsten said, what you are suggesting can be done, but if it was that
easy I'm sure it would have been done that way in the first place :-)
Ralph
Re: Protocol switch in portals
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Right. But AFAICS its never used. Do you have plans to update CopletTransformer or something?
>>
>>
>It's currently only used from the JSR 168 and the WSRP implementation.
>We could add it to the CopletTransformer if there is the need.
>
>
Ok. I think adding support for this in the Cocoon portal itself would be
a nice addition, in order for it not to be less featured than the
official specifications.
>>Can you elaborate on use cases that need absolute links?
>>
>>Shouldn't the default be to keep relative URLs unless some specific
>>secure="true|false" attribute is specified on the link (i.e. the Boolean
>>passed to LinkService is null)? That would allow the portal to run
>>smoothly on deployments where ProxyPreserveHost or proxyHost have not
>>been configured, or where the used server infrastructure doesn't support it.
>>
>>
>>
>yes, this is exactly what I meant above :) - *but* if you haven't
>configured your environment correctly, you might get into problems with
>jsr 168 and wsrp.
>
>
Right. Now projects that use Cocoon as a complete solution don't really
care about jsr168 and WSRP!
So, restating my question as I'd really like to know, what are the use
cases that require URL absolutization other than when a coplet/portlet
wants to enforce the protocol?
This is because we could avoid absolutizing except when the portlet ask
for a particular protocol, i.e. the Boolean parameter in getLinkURI() is
not null.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Protocol switch in portals (was Re: furious anger: portal broken)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> Right. But AFAICS its never used. Do you have plans to update
> CopletTransformer or something?
>
It's currently only used from the JSR 168 and the WSRP implementation.
We could add it to the CopletTransformer if there is the need.
>
>>As I said yesterday, we could create relative links if the procotol is
>>not changed, but there are cases where we need absolute links.
>>
>>
>
>
> Can you elaborate on use cases that need absolute links?
>
> Shouldn't the default be to keep relative URLs unless some specific
> secure="true|false" attribute is specified on the link (i.e. the Boolean
> passed to LinkService is null)? That would allow the portal to run
> smoothly on deployments where ProxyPreserveHost or proxyHost have not
> been configured, or where the used server infrastructure doesn't support it.
>
yes, this is exactly what I meant above :) - *but* if you haven't
configured your environment correctly, you might get into problems with
jsr 168 and wsrp.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Protocol switch in portals (was Re: furious anger: portal broken)
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>I'm a total newbie on this matter, so that may be dumb questions. I
>>don't see how absolutizing links allows this: the result of
>>absolutization is that all links use the protocol that was used by the
>>current request, i.e. if it's http than all links will use http and if
>>it's https then all links will use https.
>>
>>It seems to me that the protocol to be used depends on the page that is
>>to be displayed rather than where you come from to that page, no?
>>Absolutization means that once you enter the site using a particular
>>protocol, you always use that one. Or did I missed something?
>>
>>
>>
>The LinkService accepts a boolean argument indicating if you want a
>secure link. If this is set to true then the service switches to https.
>
>
Right. But AFAICS its never used. Do you have plans to update
CopletTransformer or something?
>As I said yesterday, we could create relative links if the procotol is
>not changed, but there are cases where we need absolute links.
>
>
Can you elaborate on use cases that need absolute links?
Shouldn't the default be to keep relative URLs unless some specific
secure="true|false" attribute is specified on the link (i.e. the Boolean
passed to LinkService is null)? That would allow the portal to run
smoothly on deployments where ProxyPreserveHost or proxyHost have not
been configured, or where the used server infrastructure doesn't support it.
And this leads to another question: what if the deployment uses
httpd+mod_ssl that proxies to the servlet engine over http? The protocol
seen by the servlet engine will be http, leading all links to be
switched to an insecure protocol.
BTW, I guess there's a potential bug in DefaultLinkService, as the port
number is added to the URL only if it's not 80, whereas https uses port
443. That means that if you ever use https on port 80 (yeah I know it's
weird), generated urls will use the default port, ie 443.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Protocol switch in portals (was Re: furious anger: portal broken)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> I'm a total newbie on this matter, so that may be dumb questions. I
> don't see how absolutizing links allows this: the result of
> absolutization is that all links use the protocol that was used by the
> current request, i.e. if it's http than all links will use http and if
> it's https then all links will use https.
>
> It seems to me that the protocol to be used depends on the page that is
> to be displayed rather than where you come from to that page, no?
> Absolutization means that once you enter the site using a particular
> protocol, you always use that one. Or did I missed something?
>
The LinkService accepts a boolean argument indicating if you want a
secure link. If this is set to true then the service switches to https.
As I said yesterday, we could create relative links if the procotol is
not changed, but there are cases where we need absolute links.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/