SSO: Add A Computer process does not redirect to plans page if user is not subscribed to an Ubuntu One plan

This is apparently an issue with not being logged in, rather than not being subscribed. But this might shed some new light on that bug.

Stuart, can you track this down? It's not clear whether the problem is on the Ubuntu One side or the SSO side - either way, it's something that needs smoothing out.

What would help here are some exact steps to reproduce the bug.

Like:

1. clear all launchpad.net and ubuntu.com cookies
2. go to https://one.ubuntu.com/

etc.

Here are the steps to reproduce.

1. Create a new LP account.
2. Ensure that you are using a computer user account without an OAuth
token. Launch the Ubuntu One sync client.
3. Wait for web browser to appear for the OAuth process.
4. Login to LP with the new LP account.
5. User is rederected to LP instead of Add a computer page.

I understand why we take them to the Add a computer page. They don't
have a subscription yet. But we should send them to the plans page to
create a subscription instead of rederecting back to the LP login page.

On Oct 8, 2009, at 12:08 PM, Steve Alexander <email address hidden>
wrote:

> What would help here are some exact steps to reproduce the bug.
>
> Like:
>
> 1. clear all launchpad.net and ubuntu.com cookies
> 2. go to https://one.ubuntu.com/
>
> etc.
>
> --
> Add A Computer process does not redirect to plans page if user is
> not subscribed to an Ubuntu One plan
> https://bugs.launchpad.net/bugs/446020
> You received this bug notification because you are a member of Ubuntu
> One hackers, which is subscribed to Ubuntu One Servers.
>
> Status in Ubuntu One Servers: Triaged
>
> Bug description:
> A user must already subscribe to an Ubuntu One plan before launching
> and completing the Add A Computer process. A better user experience
> would be if the user was redirected from the Launchpad login to the /
> plans page if they don't already subscribe to a plan. Currently, non-
> subscribers remain in a loop redirecting back to the Launchpad login
> page.

Thanks for the repro steps, Matt. Not yet had a chance to look at this.

With these steps in both Midori and Epiphany, I am simply getting an error connecting to localhost. The server redirects to the callback, which then redirects to the plans page. Hrmm...

In Firefox I get an error page from the applet. I don't know why Midori or Epiphany can't connect to localhost...

Looks like the redirection to /plans may have been slightly broken since the update to OAuth 1.0a, but not in the way described here (the looping of LP login sounds like a separate issue).

Assigning to dobey since he's looking at it anyway and has a branch; dobey, please give it back if you're not actually working on it :)

I was trying to login to one.ubuntu.com/contacts/ this morning, and hit a login loop. Turned on livehttpheaders and went through the loop 3 times recording the traffic, so maybe this provides some clues?

I'm attaching a header capture for the openid loop.

The step between the last two requests is done by Javascript automatically submitting the openid form to go back to the Launchpad login screen.

The suspicious part is the 304 NOT MODIFIED https://one.ubuntu.com/oauth/authorize returns. If I empty my browser page cache (not even the cookies), the loop doesn't happen.