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)

defect

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).
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.
(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.
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.
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
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.
-> .8 for decisions
Target Milestone: 5.12.7 → 5.12.8
Blocks: 629770
Switching to X-SendFille + fallbacks in https://github.com/jbalogh/zamboni/commit/055a15b
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Is this QA testable without running SQL queries?
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!!!!
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.