Fix potential URL conflicts with Addon pages in the devhub (slugs)

VERIFIED FIXED in 5.12.9

Status

addons.mozilla.org Graveyard
Developer Pages
P3
normal
VERIFIED FIXED
7 years ago
2 years ago

People

(Reporter: kumar, Assigned: andym)

Tracking

unspecified
5.12.9

Details

(Whiteboard: [See comment 6])

Attachments

(2 attachments)

Currently these dev URLs exist or about to exist:

/developers/addon/submit/1
/developers/addon/submit/2
...

/developers/addon/validate

But add-on slugs are also supported, such as:

/developers/addon/firebug-0.5/edit

This will conflict with add-ons having slugs such as submit or validate.  We could either blacklist slug names, which would be error prone and cumbersome to maintain, or we could change the URLs for submission, validation, etc.
Hiding to avoid any opportunistic slugging.

Do add-on slugs check against the username blacklist? If so, we can add the needed slugs to that blacklist. Any slugs unsuitable for one can also be unsuitable for another.
Group: client-services-security
I put the /addon/:slug matching at the bottom of urls.py for this reason. Anyone trying these shenanigans won't be able to access their add-on.
So it won't break our tools but it will break their add-on, so we should disallow changing to reserved slugs.
Group: client-services-security
Target Milestone: --- → Q1 2011
(In reply to comment #3)
> So it won't break our tools but it will break their add-on, so we should
> disallow changing to reserved slugs.

I thought there was already a bug for this, but maybe I'm confusing that with the one to support reserved tags.
(In reply to comment #2)
> I put the /addon/:slug matching at the bottom of urls.py for this reason.
> Anyone trying these shenanigans won't be able to access their add-on.

for non-malicious users who end up with an Add-on slug 'submit' (is that possible?) then wouldn't their time on devhub be sad and confusing?

Seems to me like an easier fix would be to provide different URLs as long as breaking historic remora URLs isn't a problem.
This bug is about:

- adding an `addons_blacklistedslug` table
- disallowing slugs to be saved if their slug exists in that table
- disallowing numeric slugs (to prevent weirdness with our add-on id redirects)
- we don't need a CRUD front end on the table for now, we can run queries on the db manually
Assignee: nobody → amckay
Priority: -- → P3
Whiteboard: [See comment 6]
Target Milestone: Q1 2011 → 5.12.9
(In reply to comment #6)
> This bug is about:
> 
> - adding an `addons_blacklistedslug` table

Is there any reason to keep this separate from the username blacklist? They serve mostly the same purpose.

> - disallowing numeric slugs (to prevent weirdness with our add-on id redirects)

That's already enforced in Addon.clean_slug.
> > - adding an `addons_blacklistedslug` table
> 
> Is there any reason to keep this separate from the username blacklist? They
> serve mostly the same purpose.

Less confusion a year from now
(Assignee)

Comment 9

7 years ago
https://github.com/jbalogh/zamboni/commit/8f4ff1b41c6adc2eeb8b941928de8eabef507a1d
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 10

7 years ago
verified that 

* 'submit' and 'validate' are not allowed slugs anymore.
* numeric slugs are not allowed

For some crazy reason, we do not allow hypen-only slugs.
Status: RESOLVED → VERIFIED

Comment 11

7 years ago
Created attachment 511297 [details]
post-fix screenshot

Comment 12

7 years ago
Created attachment 511298 [details]
post-fix screenshot
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.