portals-portalapps-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Woonsan Ko (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (APA-30) Cookies are not maintained with ReverseProxyService component when page is redirected from plain page to secure page.
Date Mon, 25 Jan 2010 20:55:34 GMT

     [ https://issues.apache.org/jira/browse/APA-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Woonsan Ko resolved APA-30.
---------------------------

    Resolution: Fixed

Fixed.
The secured property of cookies written by reverse proxy service should comply with the secure
mode of the current request channel. Also, keeps the version.

> Cookies are not maintained with ReverseProxyService component when page is redirected
from plain page to secure page.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: APA-30
>                 URL: https://issues.apache.org/jira/browse/APA-30
>             Project: Portals Apps
>          Issue Type: Bug
>          Components: apa-webcontent
>    Affects Versions: apa-webcontent-1.1
>            Reporter: Woonsan Ko
>            Assignee: Woonsan Ko
>             Fix For: apa-webcontent-1.1
>
>
> The reverse proxy service (servlet) which is used by ReverseProxyIFramePortlet translated
cookie paths to local proxy paths.
> For example, a google page sets a cookie with path, "/", then the service component can
translate the path to "/webcontent/rproxy/www.google.com/" to localize the cookie.
> (By the way, this site must be mapped like this: /rproxy/www.google.com/ --> http://www.google.com/.)
> Also we can have one more configuration for secured urls like /rproxy/secure/www.google.com/
--> https://www.google.com/.
> If a page from non secured url like http://www.google.com/ sends Set-Cookie header, then
the cookie must be a secured one like the following example:
>     Set-Cookie	Country=us; Path=/; Secure
> The problem here is that if this cookie is translated by the default reverse proxy service,
the cookie is still "Secure" one, but the current page url is not secure one. (e.g. http://localhost:8080/webcontent/rproxy/secure/www.google.com/.)
> Because of this, the next page requests cannot send the cookies sent by the server.
> Therefore, the cookies must be translated into ones as same url scheme as the cookie's.
> If the current portal url is non-secured, then the cookie's "Secure" property must be
ignored.
> Otherwise, it can be kept.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message