You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Brian Eaton (JIRA)" <ji...@apache.org> on 2008/07/11 02:49:31 UTC
[jira] Created: (SHINDIG-444) HttpCache is insecure for
authenticated content
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.
[jira] Commented: (SHINDIG-444) HttpCache is insecure for
authenticated content
Posted by "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.
[jira] Updated: (SHINDIG-444) HttpCache is insecure for
authenticated content
Posted by "Brian Eaton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Eaton updated SHINDIG-444:
--------------------------------
Attachment: authncache.patch
There's some careful use of JSON to generate cache keys in here.
I'll add OAuth caching once this patch is ACKed and committed.
> 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
> Attachments: authncache.patch
>
>
> 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.
[jira] Resolved: (SHINDIG-444) HttpCache is insecure for
authenticated content
Posted by "Brian Eaton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Eaton resolved SHINDIG-444.
---------------------------------
Resolution: Fixed
> 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
> Attachments: authncache.patch
>
>
> 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.