You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Subbarao Ayyagari (JIRA)" <ax...@ws.apache.org> on 2005/06/08 21:41:17 UTC

[jira] Created: (AXIS-2045) HTTPSender - Cookie Management

HTTPSender - Cookie Management
------------------------------

         Key: AXIS-2045
         URL: http://issues.apache.org/jira/browse/AXIS-2045
     Project: Axis
        Type: Bug
  Components: Basic Architecture  
    Versions: 1.2    
 Environment: WebService running behind SiteMinder.
    Reporter: Subbarao Ayyagari


The handleCookie method in HTTPSender.java has coulple of issues:
     1. It assumes NAME=VALUE of a session cookie remains constant. To find out if a cookie already exists are not, it uses cookies.indexOf(cookie)==-1 check. 
         While the assumption of a session cookies NAME=VALUE pair remains same is true for most of the cases, it is not true with SiteMinder. SiteMinder's SMSESSION cookie has a different value each time a request is made. With the above check, the HTTPSender ends up thinking each unique SMSESSION=NEW_VALUE as a different cookie and adds it to the subsequent requests. This throws SiteMinder off as there are now multiple SMSESSION cookies.
         One way to fix this is to check for NAME match rather than NAME=VALUE match in the list of cookies. 

     2. The class doesn't parse the "Set-Cookie" HEADER to see if the cookie is EXPIRED or not. Thus causing it to send even the expired cookies back to the Server on subsequent requests. We can leverage some of the cookie parsing code in Apache Commons HttpClient library that smartly checks for expiry, domain, path etc.

Thanks

-- 
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

[jira] Commented: (AXIS-2045) HTTPSender - Cookie Management

Posted by "Davanum Srinivas (JIRA)" <ax...@ws.apache.org>.
    [ http://issues.apache.org/jira/browse/AXIS-2045?page=comments#action_12313096 ] 

Davanum Srinivas commented on AXIS-2045:
----------------------------------------

Please submit a patch ("cvs diff -u") against latest CVS.

thanks,
dims

> HTTPSender - Cookie Management
> ------------------------------
>
>          Key: AXIS-2045
>          URL: http://issues.apache.org/jira/browse/AXIS-2045
>      Project: Axis
>         Type: Bug
>   Components: Basic Architecture
>     Versions: 1.2
>  Environment: WebService running behind SiteMinder.
>     Reporter: Subbarao Ayyagari

>
> The handleCookie method in HTTPSender.java has coulple of issues:
>      1. It assumes NAME=VALUE of a session cookie remains constant. To find out if a cookie already exists are not, it uses cookies.indexOf(cookie)==-1 check. 
>          While the assumption of a session cookies NAME=VALUE pair remains same is true for most of the cases, it is not true with SiteMinder. SiteMinder's SMSESSION cookie has a different value each time a request is made. With the above check, the HTTPSender ends up thinking each unique SMSESSION=NEW_VALUE as a different cookie and adds it to the subsequent requests. This throws SiteMinder off as there are now multiple SMSESSION cookies.
>          One way to fix this is to check for NAME match rather than NAME=VALUE match in the list of cookies. 
>      2. The class doesn't parse the "Set-Cookie" HEADER to see if the cookie is EXPIRED or not. Thus causing it to send even the expired cookies back to the Server on subsequent requests. We can leverage some of the cookie parsing code in Apache Commons HttpClient library that smartly checks for expiry, domain, path etc.
> Thanks

-- 
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

[jira] Assigned: (AXIS-2045) HTTPSender - Cookie Management

Posted by "Davanum Srinivas (JIRA)" <ax...@ws.apache.org>.
     [ http://issues.apache.org/jira/browse/AXIS-2045?page=all ]

Davanum Srinivas reassigned AXIS-2045:
--------------------------------------

    Assign To: Jayachandra Sekhara Rao Sunkara

> HTTPSender - Cookie Management
> ------------------------------
>
>          Key: AXIS-2045
>          URL: http://issues.apache.org/jira/browse/AXIS-2045
>      Project: Axis
>         Type: Bug
>   Components: Basic Architecture
>     Versions: 1.2
>  Environment: WebService running behind SiteMinder.
>     Reporter: Subbarao Ayyagari
>     Assignee: Jayachandra Sekhara Rao Sunkara

>
> The handleCookie method in HTTPSender.java has coulple of issues:
>      1. It assumes NAME=VALUE of a session cookie remains constant. To find out if a cookie already exists are not, it uses cookies.indexOf(cookie)==-1 check. 
>          While the assumption of a session cookies NAME=VALUE pair remains same is true for most of the cases, it is not true with SiteMinder. SiteMinder's SMSESSION cookie has a different value each time a request is made. With the above check, the HTTPSender ends up thinking each unique SMSESSION=NEW_VALUE as a different cookie and adds it to the subsequent requests. This throws SiteMinder off as there are now multiple SMSESSION cookies.
>          One way to fix this is to check for NAME match rather than NAME=VALUE match in the list of cookies. 
>      2. The class doesn't parse the "Set-Cookie" HEADER to see if the cookie is EXPIRED or not. Thus causing it to send even the expired cookies back to the Server on subsequent requests. We can leverage some of the cookie parsing code in Apache Commons HttpClient library that smartly checks for expiry, domain, path etc.
> Thanks

-- 
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

[jira] Commented: (AXIS-2045) HTTPSender - Cookie Management

Posted by "Subbarao Ayyagari (JIRA)" <ax...@ws.apache.org>.
    [ http://issues.apache.org/jira/browse/AXIS-2045?page=comments#action_12313317 ] 

Subbarao Ayyagari commented on AXIS-2045:
-----------------------------------------

The cookie hadling gets real complex pretty quickly. Apache Commons HttpClient has does done a good job at creating a CookieSpec and different implementations to parse cookies. How much of compile time dependency can we have with this HttpClient library if we want to leverage the code already written? 

I have temporarily hacked up my copy to skip the expired cookies because of the tight deadlines. It may be couple of weeks before I can work on issue#1 to submit a clean patch. The issue#2, like I said depends on this project strategy.

> HTTPSender - Cookie Management
> ------------------------------
>
>          Key: AXIS-2045
>          URL: http://issues.apache.org/jira/browse/AXIS-2045
>      Project: Axis
>         Type: Bug
>   Components: Basic Architecture
>     Versions: 1.2
>  Environment: WebService running behind SiteMinder.
>     Reporter: Subbarao Ayyagari
>     Assignee: Jayachandra Sekhara Rao Sunkara

>
> The handleCookie method in HTTPSender.java has coulple of issues:
>      1. It assumes NAME=VALUE of a session cookie remains constant. To find out if a cookie already exists are not, it uses cookies.indexOf(cookie)==-1 check. 
>          While the assumption of a session cookies NAME=VALUE pair remains same is true for most of the cases, it is not true with SiteMinder. SiteMinder's SMSESSION cookie has a different value each time a request is made. With the above check, the HTTPSender ends up thinking each unique SMSESSION=NEW_VALUE as a different cookie and adds it to the subsequent requests. This throws SiteMinder off as there are now multiple SMSESSION cookies.
>          One way to fix this is to check for NAME match rather than NAME=VALUE match in the list of cookies. 
>      2. The class doesn't parse the "Set-Cookie" HEADER to see if the cookie is EXPIRED or not. Thus causing it to send even the expired cookies back to the Server on subsequent requests. We can leverage some of the cookie parsing code in Apache Commons HttpClient library that smartly checks for expiry, domain, path etc.
> Thanks

-- 
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