478252 - [W-1.6.2] Login Page

Status: RESOLVED WONTFIX

(addons.mozilla.org Graveyard :: Collections, defect)

Description

[Justin Scott [:fligtar]]

Per the spec, need a mini login page for AMO to be displayed in the extension.

Comment 1

[Justin Scott [:fligtar]]

Attachment: mockup

This is a mockup of what I'm thinking the login dialog should look like. When an AMO cookie doesn't exist in the extension, the extension should open a smaller dialog or window with this page on AMO.

If the login is successful, the session cookie should be set and the window/dialog should be closed. If it is not successful, an error should be displayed, still using this same layout.

If the user clicks to create a new account or forgot their password, the window should be closed and a new tab in the browser should be opened with the normal page.

Comment 2

[Brian King [:kinger]]

FYI from the spec (E-1.2.2):

Login Dialog - If there is no existing active session and an API request requires authentication, a small browser window should appear with the AMO login webpage. After the user logs in, the dialog closes and can then use the newly set session cookie for authentication.

Comment 3

[Brian King [:kinger]]

Assigning to Justin for re-assignment.

We've determined firstrun/startup is too obtrusive for this. Here is my thinking. Right now if no cookie / login is found, the No Subscriptions panel is shown. I think we need to make a different Login panel where the user can manually kick things off, via some intro text and a button perhaps. The No Subscriptions panel should only show when the user is logged in but has no subscriptions. Thoughts?

Comment 4

[David McNamara [:mackers]]

(In reply to comment #3)
> We've determined firstrun/startup is too obtrusive for this. Here is my
> thinking. Right now if no cookie / login is found, the No Subscriptions panel
> is shown. I think we need to make a different Login panel where the user can
> manually kick things off, via some intro text and a button perhaps. The No
> Subscriptions panel should only show when the user is logged in but has no
> subscriptions. Thoughts?

The "not authenticated in AMO" behaviour has been implemented like this.

Revision 23059.

Comment 5

[Justin Scott [:fligtar]]

Okay, I'm trying to think through the login requirements.

* In order to check a subscription for updates, a user has to be logged in, which means users should be logged in all the time, for as long as possible
* Users need to login before they can use the extension's functionality

I don't want to randomly prompt the user to login to AMO when their cookie expires after 2 weeks. I think that would be pretty confusing if not connected with an action they just took.

After talking with Nick, I think the best way to accomplish this is setting a permanent token cookie that allows read-only access to the user's subscriptions to check for updates. That way, any time a user needs to interact further, they will have to open the Add-ons Manager and will then be able to see that they need to log in.

The token cookie will be re-set upon a successful login so that if the user switches accounts, it will update accordingly. We should also look into extending the login cookie's duration if the user logs in from Bandwagon.

I will spec this out and plan implementation in the API if it sounds good to you.

Comment 6

[David McNamara [:mackers]]

(In reply to comment #5)
> I will spec this out and plan implementation in the API if it sounds good to
> you.

It sounds like a good solution.

In the spec, please pay some attention to how the extension will behave when in "read-only" mode. Should we make it immediately obvious to the user (in the extension manager) that we are in read-only mode and that they should log-in. Or should we only make it aware to them when they try to do some action that requires write-access.

Comment 7

[Justin Scott [:fligtar]]

Les, what do you think of this? I think we had discussed the idea of having a separate login cookie that doesn't expire for bandwagon instead?

Comment 8

[Justin Scott [:fligtar]]

Ok, the new plan is that Bandwagon will have its own login page that sets it own login cookie that never expires. Being logged into the AMO site is no longer sufficient for the extension's functionality -- the API should only acknowledge the bandwagon cookie. The bandwagon login page should implement the JS triggers from bug 482998.

It is possible, though unlikely, that a user could be logged into the AMO site with a different account than their currently logged-in bandwagon account.

I will make a different mock for this login page because I think it should be sufficiently distinct from the normal AMO login page so that the two are not considered interchangeable.

Having a cookie that never expires will allow feeds to check for updates without worrying about the 2 week cookie expiration, but will also not anger those who don't want the AMO login cookie to persist past 2 weeks.

Thoughts?

Comment 9

[Brian King [:kinger]]

(In reply to comment #8)
> It is possible, though unlikely, that a user could be logged into the AMO site
> with a different account than their currently logged-in bandwagon account.

....

> Thoughts?

My crystal ball sees user confusion!

Comment 10

[Nick Nguyen [:osunick]]

This is really analogous to a standalone app- from the user's perspective they're logging into the add-on, but there's no login on the site that says "bandwagon login".  We'll show the current logged in user in the extension prefs.

Comment 11

[David McNamara [:mackers]]

(In reply to comment #9) 
> My crystal ball sees user confusion!

I don't think there'll be much user confusion. From the user's point of view, the site and the extension are distinct, and having to log into each separately is not really against their expectations.

I like this solution; it's far more elegant than having "read" and "write" cookies and having to worry about the state of the extension depending on what cookies are available and then having to convey that to the user.

Comment 12

[Les Orchard [:lorchard]]

If you're moving away from the AMO session cookie, I don't see the point of establishing yet another cookie.  Using cookies for an extension is a hack to begin with - the only real payoff is that you can just piggyback off an existing login flow, and this direction nixes that payoff.

A cleaner way would be to introduce an API login resource that accepts HTTP basic auth over SSL and yields an auth token.  Accept the auth token for authentication in the rest of the API instead of the AMO session cookie.  Let the extension provide its own login dialog and manage its auth token according to its own retention rules independent of cookies.

Even better would be to use something like OAuth, but I don't want to call MFBT this early in the day.

Comment 13

[Justin Scott [:fligtar]]

Hmm, Les is right about there not really being a benefit to using cookies if the user can't use the same session for website and extension. So, now it looks like we're back to where we started.

To be clear: the problem we have with using the AMO session cookie is that it expires after 2 weeks. If we could get around that problem I would still be in favor of having the same AMO and extension session.

Since that doesn't seem feasible, we'll go back to logging in through the extension and storing credentials in the Login Manager.

Les, will you have time next week to write up how the login resource should work, since you know what you're talking about? If you don't have time to actually implement it, I can probably find someone else to work on that part.

Comment 14

[Nick Nguyen [:osunick]]

There is one benefit-

We don't have to implement a login flow in the extension if we use cookies, we could use a simple php login page.  But the main thing I care about is not making users log in every 2 weeks to use the extension.

Comment 15

[Les Orchard [:lorchard]]

I wouldn't say a PHP login page is any simpler than an extension login dialog.  Still need to build a Cake controller, templates, model for the custom tokens, do validation, etc & so forth.

If we go with an API login resource, there wouldn't be much to it on the server side.  Less than a PHP login page, actually.  I could look into specing that next week and probably implement pretty quickly.

Just to throw another monkey wrench in there, but I do clear my cookies pretty regularly.  Not sure if it's been considered in the extension interactions, but even a "permanent" cookie can disappear.  Another reason I dislike the idea of extensions piggybacking on cookies outside their control. :)

Comment 16

[David McNamara [:mackers]]

It has been decided to go the API login route.

Bug 486145

Comment 17

[Justin Scott [:fligtar]]

WONTFIXing, as we're now handling this in the extension.