Closed Bug 643482 Opened 13 years ago Closed 13 years ago

Use a token to view binary content in the editor tools

Categories

(addons.mozilla.org Graveyard :: Admin/Editor Tools, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: clouserw, Assigned: andy+bugzilla)

References

Details

We use StAMN to view binary files in add-ons, but due to not all add-ons being open source, we can't view like normal.  So, the plan we came up with on the phone:

1) Disable Apache's "+10 years" caching on these pages (either /files/ and /diff, or /editors/ or something)

2) Add a unique token to the URL that expires at some point (+20 minutes?) from when it is assigned.

3) The token is checked for expiration and validity with each request (when assigned, store the IP - make sure that doesn't change)

4) We can store the token in memcache to avoid another table.
Blocks: 645720, 645747
Target Milestone: Q2 2011 → 6.0.7
I was going to suggest the token is one off and we discard it from memcache when it's used. Then we don't need to check the IP doesn't change. This should be low traffic at this point and 2 memcache operations per file shouldn't hurt.
(In reply to comment #1)
> I was going to suggest the token is one off and we discard it from memcache
> when it's used. Then we don't need to check the IP doesn't change. This should
> be low traffic at this point and 2 memcache operations per file shouldn't hurt.

(token used OR 20 min) works for me.  I'm wondering if we'll need to poll once or twice.  We're talking about generating a token and using it for another request in an iframe on the same page.  The timing of that sounds like the cause of future headaches if we don't make it flexible about when the token shows up.
Fair enough on the time, I'm checking the IP and have dropped it down to one minute. The user will just get a addons link that's a redirect so it will appear pretty transparent to the end user.
https://github.com/jbalogh/zamboni/commit/9840be92348a76a0b588d8d23579f0e9f359c14a

oremj: we need to stop .../files/browse/\d+/file-serve/... from having the 10 yr cache on it on preview. 

For example:

/en-US/firefox/files/browse/51/file-serve/som.js?token=2913dac4-4cf2-49e0-a5f4-4b5a22e280bc
Assignee: amckay → jeremy.orem+bugs
11:12 < jbalogh> https://github.com/jbalogh/zamboni/blob/master/media/.htaccess
11:12 < oremj> yeah, nothing in the vhost
11:12 < clouserw> oh, perfect
11:13 < clouserw> can one of you put that in the bug?
11:13 < clouserw> or I can, but I'm taking credit then!
Assignee: jeremy.orem+bugs → clouserw
Assignee: clouserw → amckay
Target Milestone: 6.0.7 → 6.0.8
Blocks: 652979
Changes made as per email with oremj. Reminder for when we go to production to change X-Sendfile path so it can access the files.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Checked with https://addons-cdn.allizom.org/en-US/firefox/files/browse/116584/file-serve/searchplugin/conduit.gif?token=053208ca-cb51-41d2-8d44-73e6a517695c

Editing the token results in a 403. Marking this as verified.
Status: RESOLVED → VERIFIED
The change needed for st.a.m.o is something like:

   RewriteCond %{REQUEST_URI}
/[\w-]+/\w+/files/browse/\d+/file-serve/.*$
   RewriteRule . - [E=IS_CDN_REQ:true]
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.