[
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/[EMAIL
> PROTECTED]
> 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.
