You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by "Les Hazlewood (JIRA)" <ji...@apache.org> on 2010/02/19 18:02:27 UTC

[jira] Created: (SHIRO-139) Cookie support refactoring - Simplify cookie configuration, support HttpOnly cookies and default session cookies to be HttpOnly = true

Cookie support refactoring - Simplify cookie configuration, support HttpOnly cookies and default session cookies to be HttpOnly = true
--------------------------------------------------------------------------------------------------------------------------------------

                 Key: SHIRO-139
                 URL: https://issues.apache.org/jira/browse/SHIRO-139
             Project: Shiro
          Issue Type: Improvement
          Components: Web
    Affects Versions: 1.0.0
            Reporter: Les Hazlewood
             Fix For: 1.0.0


It would also be prudent to refactor the cookie support in Shiro to 

1) remove the overly verbose and complex RequestAttribute / CookieRequestAttribute concepts.  This existed as a way to shield Shiro from implementation details on how to persist and retrieve data across requests.  It'd be better to allow end-users to just configure a Cookie pojo instance that is set on cookie-capable components which in turn use a mechanism to set/remove the cookie

2) support the notion of HttpOnly cookies, which the servlet 2.4/2.5 does not support, but we could support with our own Cookie pojo used in configuration (see #1) which we set on the response header directly ( response.setHeader instead of response.addCookie)

3) After adding #2, default Shiro's session cookie to be HttpOnly = true for added security to reduce XSS attacks.

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


[jira] Commented: (SHIRO-139) Cookie support refactoring - Simplify cookie configuration, support HttpOnly cookies and default session cookies to be HttpOnly = true

Posted by "Les Hazlewood (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SHIRO-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867453#action_12867453 ] 

Les Hazlewood commented on SHIRO-139:
-------------------------------------

Just a quick note - per this mailing list thread:

http://mail-archives.apache.org/mod_mbox/incubator-shiro-user/201005.mbox/%3CAANLkTim9IQYMwJ4IduhzOXUsQmPrSdpgh9i5ikmwNqt1@mail.gmail.com%3E

It was discovered that the outgoing deleting 'rememberMe' cookie value was overwriting the incoming 'rememberMe' cookie value.  The SimpleCookie.removeFrom method was refactored to not use an incoming javax.servlet.http.Cookie, change it's value and maxAge for deletion, and then use that same Cookie instance in the response.addCookies call to delete the cookie.  Now the 'removeFrom' implementation sets the 'Set-Cookie' header just like the 'saveTo' implementation to avoid any possibility of sharing javax.servlet.http.Cookie objects. 

The SimpleCookieTest and CookieRememberMeManagerTest classes were updated to reflect this refactoring.

> Cookie support refactoring - Simplify cookie configuration, support HttpOnly cookies and default session cookies to be HttpOnly = true
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SHIRO-139
>                 URL: https://issues.apache.org/jira/browse/SHIRO-139
>             Project: Shiro
>          Issue Type: Improvement
>          Components: Web
>    Affects Versions: 1.0.0
>            Reporter: Les Hazlewood
>             Fix For: 1.0.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It would also be prudent to refactor the cookie support in Shiro to 
> 1) remove the overly verbose and complex RequestAttribute / CookieRequestAttribute concepts.  This existed as a way to shield Shiro from implementation details on how to persist and retrieve data across requests.  It'd be better to allow end-users to just configure a Cookie pojo instance that is set on cookie-capable components which in turn use a mechanism to set/remove the cookie
> 2) support the notion of HttpOnly cookies, which the servlet 2.4/2.5 does not support, but we could support with our own Cookie pojo used in configuration (see #1) which we set on the response header directly ( response.setHeader instead of response.addCookie)
> 3) After adding #2, default Shiro's session cookie to be HttpOnly = true for added security to reduce XSS attacks.

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


[jira] Resolved: (SHIRO-139) Cookie support refactoring - Simplify cookie configuration, support HttpOnly cookies and default session cookies to be HttpOnly = true

Posted by "Les Hazlewood (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SHIRO-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Les Hazlewood resolved SHIRO-139.
---------------------------------

    Resolution: Fixed

org.apache.shiro.web.servlet.Cookie interface now provides isHttpOnly() and setHttpOnly(boolean httpOnly) methods and the org.apache.shiro.web.servlet.SimpleCookie implementation supports setting the 'Set-Cookie' header with the HttpOnly flag as necessary.

> Cookie support refactoring - Simplify cookie configuration, support HttpOnly cookies and default session cookies to be HttpOnly = true
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SHIRO-139
>                 URL: https://issues.apache.org/jira/browse/SHIRO-139
>             Project: Shiro
>          Issue Type: Improvement
>          Components: Web
>    Affects Versions: 1.0.0
>            Reporter: Les Hazlewood
>             Fix For: 1.0.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It would also be prudent to refactor the cookie support in Shiro to 
> 1) remove the overly verbose and complex RequestAttribute / CookieRequestAttribute concepts.  This existed as a way to shield Shiro from implementation details on how to persist and retrieve data across requests.  It'd be better to allow end-users to just configure a Cookie pojo instance that is set on cookie-capable components which in turn use a mechanism to set/remove the cookie
> 2) support the notion of HttpOnly cookies, which the servlet 2.4/2.5 does not support, but we could support with our own Cookie pojo used in configuration (see #1) which we set on the response header directly ( response.setHeader instead of response.addCookie)
> 3) After adding #2, default Shiro's session cookie to be HttpOnly = true for added security to reduce XSS attacks.

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