267098 - Getting 404 errors on approval queue

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[alanjstr]

Hendikins went to the approval queue and found that the links result in 404s. 
The directory/virtual directory /files/ does not seem to exist.  justdave can't
find it in httpd.conf or update.conf, either.

Files do seem to be getting uploaded and going into /opt/update-files/approval/
but they can't be downloaded.

Comment 1

[Wolf [:wolf]]

Urgh. I remember this now. :-) Originally the path to the update-files
repository on disk (when on rodan) was /opt/webtools/update/files/ which was a
subdirectory of update itself. Because of a bug around the time of the migration
from rodan to iguana.mozilla.org some files were slipping through with their
pre-approval URLs. (http://update.mozilla.org/files/approval/<whatever>.xpi)
Because this directory wasn't protected, it was possible for anybody to grab
files that were added pre-approval. When the site was migrated, I broke apart
the site and repository to get the repository out of the webtree.

I meant to file a bug about the resulting bustage of breaking those apart on the
approval queue for update 0.9. (it's fixed (or will be, if the approvalfile.php
script doesn't exist yet) in a different way in update-beta). So this can be
that bug. :-)

What's needed here is a redirection for /files/ to point to something under the
password protected section.. Something like /files/ --> /admin/files/ should
work. I'll poke at it.

Comment 2

[Wolf [:wolf]]

Fixed.

Also, approvalfile.php was missing from update-beta, will check that in shortly. :-)

Comment 3

[alanjstr]

So is the beta now live?  I haven't changed the way I do anything.  So why did
this work last week and not this week?

Comment 4

[Wolf [:wolf]]

No, the beta is still development, but the same bug exists for seperate reasons
on both update_09 and update_beta.

In beta, it existed because the file that fixed the approval queue repository
was no longer inside the webtree bug was 404 itself. ApprovalFile.php is part of
the DevCP, it passes through approval queue files to the client browser.

This bug has existed for awhile, it only affected downloadability of extensions
from the approval queue page. The script itself understood the new path outside
of the webtree, and can handle it. but, the files weren't exposed via the URL
used there.

Most likely the way you do stuff doesn't involve re-downloading the files from
the approval queue because you test before you add, which is why you didn't see
this. :-)