You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Ate Douma (JIRA)" <je...@portals.apache.org> on 2005/10/26 12:38:55 UTC
[jira] Updated: (JS2-204) PLT.7.1.2 Portlet URL securit y not implemented and absolute URL rendering
[ http://issues.apache.org/jira/browse/JS2-204?page=all ]
Ate Douma updated JS2-204:
--------------------------
Fix Version: 2.0-FINAL
(was: 2.0-M2)
(was: 2.0-dev/cvs)
Description:
PLT.7.1.2 PortletURL security
-----------------------------
The PortalURL doesn't yet honor a request for the explicit generation of secure or non-secure PortletURLs as required by the Portlet Specification.
Whatever the setting, a non-secure url is always generated.
I will implement this requirement using the same solution as provided by Jeremy Boyes for the Pluto PortalDriver.
See: http://issues.apache.org/jira/browse/PLUTO-82.
This solution will use two different Servlet Mappings in web.xml for the JetspeedServlet: a non-secure (what we have now already: /portal/*) and a secure (/secure/portal/*).
For the secure mapping a security-constraint with transport-garantee CONFIDENTIAL will be defined, effectively securing any access through this mapping.
These mappings are, and also need be, defined in WEB-INF/conf/jetspeed.properties too.
The AbstractPortalURL will read these properties to determine which path to use for secure and non-secure PortletURLs.
Note, these paths will *only* be used when a secure url must be generated while the current request is not, or visa versa.
This means, other mappings can still be used (we have also a /jetspeed/* mapping defined although I don't know why or if it is needed anymore) as long as there isn't a switch from secure to non-secure or visa versa.
Absolute URL Rendering
----------------------
Another problem the above solution will partly solve is the current absolute URL rendering (including the Scheme, ServerName and Portnummer in an URL) which poses problems with Proxy configurations as has been recently been reported on the list by Scott Heaberlin.
By using different mappings for the secure and non-secure access we don't need to prefix the urls with a HTTP:// or HTTPS:// scheme anymore.
I will also remove the Scheme, Servername and Portnummer encoding in url generation as currently is done by the JetspeedPowerTool, JetspeedVelocityViewServlet and the ContentLocatingRequestWrapper of the ContentServer.
was:
PLT.7.1.2 PortletURL security
-----------------------------
The PortalURL doesn't yet honor a request for the explicit generation of secure or non-secure PortletURLs as required by the Portlet Specification.
Whatever the setting, a non-secure url is always generated.
I will implement this requirement using the same solution as provided by Jeremy Boyes for the Pluto PortalDriver.
See: http://issues.apache.org/jira/browse/PLUTO-82.
This solution will use two different Servlet Mappings in web.xml for the JetspeedServlet: a non-secure (what we have now already: /portal/*) and a secure (/secure/portal/*).
For the secure mapping a security-constraint with transport-garantee CONFIDENTIAL will be defined, effectively securing any access through this mapping.
These mappings are, and also need be, defined in WEB-INF/conf/jetspeed.properties too.
The AbstractPortalURL will read these properties to determine which path to use for secure and non-secure PortletURLs.
Note, these paths will *only* be used when a secure url must be generated while the current request is not, or visa versa.
This means, other mappings can still be used (we have also a /jetspeed/* mapping defined although I don't know why or if it is needed anymore) as long as there isn't a switch from secure to non-secure or visa versa.
Absolute URL Rendering
----------------------
Another problem the above solution will partly solve is the current absolute URL rendering (including the Scheme, ServerName and Portnummer in an URL) which poses problems with Proxy configurations as has been recently been reported on the list by Scott Heaberlin.
By using different mappings for the secure and non-secure access we don't need to prefix the urls with a HTTP:// or HTTPS:// scheme anymore.
I will also remove the Scheme, Servername and Portnummer encoding in url generation as currently is done by the JetspeedPowerTool, JetspeedVelocityViewServlet and the ContentLocatingRequestWrapper of the ContentServer.
Environment:
> PLT.7.1.2 Portlet URL securit y not implemented and absolute URL rendering
> --------------------------------------------------------------------------
>
> Key: JS2-204
> URL: http://issues.apache.org/jira/browse/JS2-204
> Project: Jetspeed 2
> Type: Bug
> Components: ContentServer, Profiling/Portal Navigation, Container
> Versions: 2.0-dev/cvs
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.0-FINAL
>
> PLT.7.1.2 PortletURL security
> -----------------------------
> The PortalURL doesn't yet honor a request for the explicit generation of secure or non-secure PortletURLs as required by the Portlet Specification.
> Whatever the setting, a non-secure url is always generated.
> I will implement this requirement using the same solution as provided by Jeremy Boyes for the Pluto PortalDriver.
> See: http://issues.apache.org/jira/browse/PLUTO-82.
> This solution will use two different Servlet Mappings in web.xml for the JetspeedServlet: a non-secure (what we have now already: /portal/*) and a secure (/secure/portal/*).
> For the secure mapping a security-constraint with transport-garantee CONFIDENTIAL will be defined, effectively securing any access through this mapping.
> These mappings are, and also need be, defined in WEB-INF/conf/jetspeed.properties too.
> The AbstractPortalURL will read these properties to determine which path to use for secure and non-secure PortletURLs.
> Note, these paths will *only* be used when a secure url must be generated while the current request is not, or visa versa.
> This means, other mappings can still be used (we have also a /jetspeed/* mapping defined although I don't know why or if it is needed anymore) as long as there isn't a switch from secure to non-secure or visa versa.
> Absolute URL Rendering
> ----------------------
> Another problem the above solution will partly solve is the current absolute URL rendering (including the Scheme, ServerName and Portnummer in an URL) which poses problems with Proxy configurations as has been recently been reported on the list by Scott Heaberlin.
> By using different mappings for the secure and non-secure access we don't need to prefix the urls with a HTTP:// or HTTPS:// scheme anymore.
> I will also remove the Scheme, Servername and Portnummer encoding in url generation as currently is done by the JetspeedPowerTool, JetspeedVelocityViewServlet and the ContentLocatingRequestWrapper of the ContentServer.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org