[jira] Commented: (SHINDIG-444) HttpCache is insecure for authenticated content

["Kevin Brown (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SHINDIG-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612753#action_12612753 ] 

Kevin Brown commented on SHINDIG-444:
-------------------------------------

Arbitrary strings are good, though I'd be careful about using JSON since the standard json libraries don't guarantee key order (JSON.org uses a HashMap, so key order will definitely change).

What about 

<owner>:<viewer>:<url> ?

<owner> and <viewer> can be set to zero if sign_owner / sign_viewer are false.

I also think we need oauth in there too. Maybe url encoded format?

owner=<owner>&viewer=<viewer>&oauthService=<service>&url=<url>

I have an old patch on my machine that moved most of the signed fetch and oauth logic into HttpRequest, and HttpRequest was responsible for producing the key. Something like:

HttpRequest normalRequest = new HttpRequest(url);
HttpRequest signedRequest = new SignedHttpRequest(url, securityToken);
HttpRequest oauthRequest = new OAuthRequest(url, securityToken, oauthState);

and

String key = signedRequest.getCacheKey();

You could also just make the cache key HttpRequest, though I do prefer string keys in general

> HttpCache is insecure for authenticated content
> -----------------------------------------------
>
>                 Key: SHINDIG-444
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-444
>             Project: Shindig
>          Issue Type: Bug
>            Reporter: Brian Eaton
>
> Background: http://mail-archives.apache.org/mod_mbox/incubator-shindig-dev/200805.mbox/%3Cdaf5b9570805250922u1c9b76degd393ab181ecc39d8@mail.gmail.com%3E
> Fixing this requires changing the HttpCache and AbstractHttpCache interfaces.  I'd like to change them so that the keys are strings, and the values are HttpResponses.
> Users of the HttpCache interface will figure out cache keys by building up complex strings (maybe JSON?) describing the resource.  For example, a signed fetch might look like this:
>     { url: 'http://www.example.com', signed: true, owner: 'brian', viewer: null }
> An unsigned GET might look like this:
>     { url: 'http://www.example.com' }
> Whatever string format is used would need to serialize consistently to avoid spurious cache misses.  for example, something that randomly switches between { url: foo, data: bar } and { data: bar, url: foo } would be a problem.

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