You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shindig.apache.org by "Richard Wallace (JIRA)" <ji...@apache.org> on 2009/09/08 23:43:57 UTC

[jira] Created: (SHINDIG-1167) HttpCache ignores authorization headers

HttpCache ignores authorization headers
---------------------------------------

                 Key: SHINDIG-1167
                 URL: https://issues.apache.org/jira/browse/SHINDIG-1167
             Project: Shindig
          Issue Type: Bug
          Components: Java
    Affects Versions: 1.0
            Reporter: Richard Wallace


HttpRequest Authorization headers are being ignored when deciding if the HttpRequest/HttpResponse is cacheable.  This is causing a problem in gadgets that try and use makeRequest with the OAUTH_USE_TOKEN parameter set to 'if_available' and then later makes a request to the same web services with the OAUTH_USE_TOKEN set to 'always'.  It should be respecting the Authorization header according to the [HTTP spec|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8].

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


[jira] Commented: (SHINDIG-1167) HttpCache ignores authorization headers

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SHINDIG-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752960#action_12752960 ] 

Kevin Brown commented on SHINDIG-1167:
--------------------------------------

I'm not sure I follow here. OAuth requests shouldn't be cached at all -- only 2-legged requests can be cached. Caching anything with an access token present is problematic.

> HttpCache ignores authorization headers
> ---------------------------------------
>
>                 Key: SHINDIG-1167
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1167
>             Project: Shindig
>          Issue Type: Bug
>          Components: Java
>    Affects Versions: 1.0
>            Reporter: Richard Wallace
>
> HttpRequest Authorization headers are being ignored when deciding if the HttpRequest/HttpResponse is cacheable.  This is causing a problem in gadgets that try and use makeRequest with the OAUTH_USE_TOKEN parameter set to 'if_available' and then later makes a request to the same web services with the OAUTH_USE_TOKEN set to 'always'.  It should be respecting the Authorization header according to the [HTTP spec|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8].

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


[jira] Commented: (SHINDIG-1167) HttpCache ignores authorization headers

Posted by "Richard Wallace (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SHINDIG-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753209#action_12753209 ] 

Richard Wallace commented on SHINDIG-1167:
------------------------------------------

I agree that they shouldn't be.  But they are getting cached.  I do not see anywhere in the OAuthRequest#fetchData OAuth#sanitizeAndSign or any other methods where the request is explicitly set to be non-cacheable. 

> HttpCache ignores authorization headers
> ---------------------------------------
>
>                 Key: SHINDIG-1167
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1167
>             Project: Shindig
>          Issue Type: Bug
>          Components: Java
>    Affects Versions: 1.0
>            Reporter: Richard Wallace
>
> HttpRequest Authorization headers are being ignored when deciding if the HttpRequest/HttpResponse is cacheable.  This is causing a problem in gadgets that try and use makeRequest with the OAUTH_USE_TOKEN parameter set to 'if_available' and then later makes a request to the same web services with the OAUTH_USE_TOKEN set to 'always'.  It should be respecting the Authorization header according to the [HTTP spec|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8].

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


[jira] Commented: (SHINDIG-1167) HttpCache ignores authorization headers

Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SHINDIG-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773964#action_12773964 ] 

Paul Lindner commented on SHINDIG-1167:
---------------------------------------

Richard, can you tell us if this is still a problem?


> HttpCache ignores authorization headers
> ---------------------------------------
>
>                 Key: SHINDIG-1167
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1167
>             Project: Shindig
>          Issue Type: Bug
>          Components: Java
>    Affects Versions: 1.0
>            Reporter: Richard Wallace
>
> HttpRequest Authorization headers are being ignored when deciding if the HttpRequest/HttpResponse is cacheable.  This is causing a problem in gadgets that try and use makeRequest with the OAUTH_USE_TOKEN parameter set to 'if_available' and then later makes a request to the same web services with the OAUTH_USE_TOKEN set to 'always'.  It should be respecting the Authorization header according to the [HTTP spec|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8].

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


[jira] Commented: (SHINDIG-1167) HttpCache ignores authorization headers

Posted by "Richard Wallace (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SHINDIG-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773971#action_12773971 ] 

Richard Wallace commented on SHINDIG-1167:
------------------------------------------

I believe it to be, though we're not using trunk or any of the 1.1 betas at Atlassian yet.  But I did have to apply a few patches to fix this and another issue where responses with 4xx errors were being cached when they shouldn't have.  The patch for the authorization header was a change in the HttpCacheKey

{code}
Index: atlassian/vendor/apache-shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/http/HttpCacheKey.java
===================================================================
diff -u -N -r34308 -r34576
--- atlassian/vendor/apache-shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/http/HttpCacheKey.java	(.../HttpCacheKey.java)	(revision 34308)
+++ atlassian/vendor/apache-shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/http/HttpCacheKey.java	(.../HttpCacheKey.java)	(revision 34576)
@@ -50,7 +50,8 @@
     data = Maps.newHashMap();
     setCacheable(true);
     if (!"GET".equals(request.getMethod()) ||
-        request.getIgnoreCache()) {
+        request.getIgnoreCache() ||
+        request.getHeader("Authorization") != null) {
       setCacheable(false);
     }
     // In theory we only cache GET, but including the method in the cache key
{code}

which I believe no longer exists (at least not in the same form) on trunk.

> HttpCache ignores authorization headers
> ---------------------------------------
>
>                 Key: SHINDIG-1167
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1167
>             Project: Shindig
>          Issue Type: Bug
>          Components: Java
>    Affects Versions: 1.0
>            Reporter: Richard Wallace
>
> HttpRequest Authorization headers are being ignored when deciding if the HttpRequest/HttpResponse is cacheable.  This is causing a problem in gadgets that try and use makeRequest with the OAUTH_USE_TOKEN parameter set to 'if_available' and then later makes a request to the same web services with the OAUTH_USE_TOKEN set to 'always'.  It should be respecting the Authorization header according to the [HTTP spec|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8].

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