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 14:56:20 UTC
Re: Protocol switch in portals
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
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