824720 - Allow / deny actions to unverified email users

Status: RESOLVED INVALID

(Marketplace Graveyard :: General, defect, P3)

Description

[Kumar McMillan [:kumar]]

When a user logs in with an unverified email (bug 794634) we should only allow access to certain views like installing / purchasing apps. We should deny access to other views that would work better with a verified email (such as submitting apps).

Details on what to allow/deny TBD.

Comment 1

[Christopher Van Wiemeersch [:cvan]]

Kumar,  any updates on this on what we need?

Comment 2

[Kumar McMillan [:kumar]]

A good start would be to deny unverified accounts from accessing the devhub and submitting an app. However, we only accept unverified accounts on B2G so this scenario would only happen when someone is spoofing headers to do something malicious with an anonymous email.

Comment 3

[Kumar McMillan [:kumar]]

I meant spoofing the post params not spoofing headers.

like this: https://github.com/mozilla/zamboni/blob/master/media/js/mkt/login.js#L47

Comment 4

[Matt Basta [:basta]]

With the advent of Fireplace, is it agreeable that:

- The consumer APIs should be available to unverified emails
- Non-consumer APIs, developer pages, and reviewer/admin/lookup pages should not be available to unverified emails

I'd even go so far as to say that we should be universally blocking unverified emails and only allowing them with shared secret authentication on the API (which is already applied to all consumer APIs). Heyna or no?

Comment 5

[Kumar McMillan [:kumar]]

IMO:
 
> - The consumer APIs should be available to unverified emails

Agreed

> - Non-consumer APIs, developer pages, and reviewer/admin/lookup pages should
> not be available to unverified emails

Agreed

> 
> I'd even go so far as to say that we should be universally blocking
> unverified emails and only allowing them with shared secret authentication
> on the API (which is already applied to all consumer APIs). Heyna or no?

I'm not sure what this implies; it's important to me that the above access restrictions are met.

Comment 6

[Wil Clouser [:clouserw]]

(In reply to Kumar McMillan [:kumar] from comment #5)
> IMO:
>  
> > - The consumer APIs should be available to unverified emails
> 
> Agreed
> 
> > - Non-consumer APIs, developer pages, and reviewer/admin/lookup pages should
> > not be available to unverified emails
> 
> Agreed
> 
> > 
> > I'd even go so far as to say that we should be universally blocking
> > unverified emails and only allowing them with shared secret authentication
> > on the API (which is already applied to all consumer APIs). Heyna or no?
> 
> I'm not sure what this implies; it's important to me that the above access
> restrictions are met.

I agree with everything kumar said :)

Comment 7

[David Bialer [:dbialer]]

I think this bug will eventually obsolete when we move to Firefox Accounts and all emails will be verified.

Comment 8

[Andy McKay]

Firefox Accounts