Thanks for the info, we will look into it. However, are you talking about the
RelativePortalURLImpl? We noticed that this was used now instead of
PortalURLImpl. In the past we sent a fix for the PortalURLImpl to use the
injected PortalURLParserImpl instead of having it hard coded. We noticed that
this problem was reintroduced in the RelativePortalURLImpl.
It is lines 159 -161 in the RelativePortalURLImpl.
public String toString() { return
PortalURLParserImpl.getParser().toString(this); }
This should use the injected implementation of the PortalURLParserImpl, not the
above.
Jeremy
On 12/6/07 9:40 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> setSecure() just changes the protocol in PortalURL from http to https...
> simple enough. :)
I think that the tricky part is that the default Pluto driver generates
relative URLs, so the protocol is not specified. I guess the solution
could be to subclass PortletURLProviderImpl implementation so that
isSecureSupported() returns true, add a flag for whether or not the
generated URL should be secure, and then map the PortalDriverServlet to an
alternate URL mapping (i.e., map it to /pluto/sportal or something like
that). You can then put a transport guarantee on /pluto/sportal/* in in
the deployment descriptor.
I'll create a JIRA issue for this and see if I can put together a patch
before the 1.1.5 release, but honestly I'm not sure if I can fit it in
before then.
Does anyone see any problems with the implementation described above?
-- Ben
