Closed
Bug 625099
Opened 15 years ago
Closed 15 years ago
Disabled files shouldn't be in _files
Categories
(addons.mozilla.org Graveyard :: Admin/Editor Tools, defect, P2)
addons.mozilla.org Graveyard
Admin/Editor Tools
Tracking
(Not tracked)
VERIFIED
FIXED
5.12.8
People
(Reporter: clouserw, Assigned: jbalogh)
References
Details
If a file is unreviewed or rejected we should remove it from _files/ and put it somewhere else under NETAPP_STORAGE.
The same goes for any temporary storage of files (like when submitting an add-on but not yet completing it).
| Assignee | ||
Comment 1•15 years ago
|
||
What should we do with these files? They're supposed to be accessible from public pages while an add-on is unreviewed, and they have to be accessible by editors for review.
| Reporter | ||
Comment 2•15 years ago
|
||
(In reply to comment #1)
> What should we do with these files? They're supposed to be accessible from
> public pages while an add-on is unreviewed, and they have to be accessible by
> editors for review.
If they're accessible while unreviewed, this bug is INVALID. I thought our new system wasn't going to allow any add-ons to be downloaded unless they had been reviewed.
Comment 3•15 years ago
|
||
It is true that unreviewed files can be downloaded as they will only be unreviewed for a short time.
Disabled files, however, should be quarantined.
| Reporter | ||
Comment 4•15 years ago
|
||
s/unreviewed/disabled/ then! Thanks fligtrar (typo'd it, but the result sounds like a tiger so I'm rolling with it).
Summary: Unreviewed files shouldn't be in _files → Disabled files shouldn't be in _files
| Assignee | ||
Comment 5•15 years ago
|
||
oremj: it sounds like we need to have some files behind an auth wall (/_files is completely public). Do you have any suggestions on how to achieve this. This should be extremely low-traffic so it wouldn't kill us to serve the files through Python, but I'm morally opposed to that.
| Assignee | ||
Comment 7•15 years ago
|
||
Merge: https://github.com/jbalogh/zamboni/commit/8efe4ae
Hiding files: https://github.com/jbalogh/zamboni/commit/35b885f
Serving files again: https://github.com/jbalogh/zamboni/commit/2d9d9d0
The serving part is broken until we work out bug 629770.
| Assignee | ||
Comment 8•15 years ago
|
||
Switching to X-SendFille + fallbacks in https://github.com/jbalogh/zamboni/commit/055a15b
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 9•15 years ago
|
||
Is this QA testable without running SQL queries?
| Assignee | ||
Comment 10•15 years ago
|
||
1. Upload a file.
2. Download that file, observe the /_files/ URL where it resides.
3. Disable that file.
4. Ask me to run the hide-files cronjob.
5. Ensure the file is no longer in /_files/.
6. Log out, observe a 404 from the /downloads/file/ URL for that file.
7. Log in as an admin, see that /downloads/file/ returns your file from #2.
8. Log in as a non-admin owner of that file, see that /downloads/file/ returns your file from #2.
9. Ask oremj to set XSENDFILES=False on preview, repeat #7 or #8.
10. PROFIT!!!!
Comment 11•15 years ago
|
||
verified @ https://addons-cdn.allizom.org/_files/275083/addon-1.3-fx.xpi
thanks for the STR.
Status: RESOLVED → VERIFIED
Updated•10 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•