Add-ons with invalid types should be rejected when uploaded

RESOLVED FIXED in 5.12.2

Status

addons.mozilla.org Graveyard
Developer Pages
P3
minor
RESOLVED FIXED
9 years ago
2 years ago

People

(Reporter: mossop, Assigned: basta)

Tracking

Details

(URL)

(Reporter)

Description

9 years ago
Currently you can apparently upload add-ons with invalid types in their install.rdf (add-on 13648 has type 3 f.e.). AMO should only accept add-ons with a known type.
"New in Firefox 1.5 This property was added for Firefox 1.5, and is only required for addon types other than Extensions and Themes."

In other words: It should either be undefined or valid.
(Reporter)

Comment 2

9 years ago
Sorry yes. A missing type should still be considered as type 2 or 4 as currently.
I've seen cases where Themes are uploaded without a defined type and they are recognized as Extensions by AMO. This causes some breakage, like incorrect categories showing up in the add-on properties.

I'd prefer to make the type attribute mandatory for AMO, even if Firefox doesn't do this. And, of course, reject unknown types.
Severity: normal → minor
Priority: -- → P3
Target Milestone: --- → 4.x (triaged)
What are the rules to validate here (ie. what are the types)?  Basta is already detecting add-on types, so this is easy to add.
Assignee: nobody → mbasta
(Reporter)

Comment 5

7 years ago
(In reply to comment #4)
> What are the rules to validate here (ie. what are the types)?  Basta is already
> detecting add-on types, so this is easy to add.

The types are listed here: https://developer.mozilla.org/en/Install_Manifests#type

If no type is specified but em:internalName exists then the type is considered to be 4 (theme). If no type or internalName exists then the type is 2 (extension)
(Assignee)

Comment 6

7 years ago
The new validator does a number of things for the add-on's type:

- Allows a type to be manually set. If the detected type does not match this, then the add-on is marked as rejected.
- Determines the type based on the developer's indication (i.e.: <em:type>). If this does not match the detected type, the add-on is rejected.
- Detects the type based on filename, file content, package structure, and other factors.

The detected type is what is used by the validator during any processing of the add-on beyond type detection.
Target Milestone: 4.x (triaged) → 5.12.2
(Assignee)

Comment 7

7 years ago
Just looked it up: this is already implemented in the new validator and is present in the validator's zamboni implementation.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 8

7 years ago
I was able to upload an add-on with <em:type>21</em:type> . I did not see any error messages.

reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 9

7 years ago
I'm assuming you tested on the new validator. Could you email me a copy of the add-on that you uploaded? There's definitely code in there that *should* be throwing errors for invalid <em:type> values (and there should be unit tests for), but if it's failing, I'll need to see what's causing it.

mbasta@mozilla.com

Thanks!

Comment 10

7 years ago
I did not know remora still pointed to the old validator. My mistake.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.