Cannot sign up for SoundCloud in Desktop WebRT - Redirects Off-Origin on Sign Up

VERIFIED FIXED

Status

Tech Evangelism Graveyard
English US
VERIFIED FIXED
6 years ago
3 years ago

People

(Reporter: ticachica, Unassigned)

Tracking

Details

(Whiteboard: [topapps])

(Reporter)

Description

6 years ago
I installed SoundCloud and was trying to Signup for an account. I ran into some unexpected behavior. See the two use cases below.

Mac OS X 10.6.8
Firefox is not running
Nightly 15.0a1 (2012-05-02)

Launch SoundCloud from the Applications folder
Click "Sign up button"
A pop up frame shows up
Fill in foo@foo.com in the e-mail field
Fill in 1111 in the password fields
Uncheck "Yes, send me useful news about SoundCloud"
Check "I agree to the Terms of use and Privacy Policy"

Click "Sign Up"

Overlay popup goes away and I'm on the same start page. Nothing seems to have happened. I am not logged in and no account has been created.


Mac OS X 10.6.8
Firefox is running
Nightly 15.0a1 (2012-05-02)

Launch SoundCloud from the Applications folder
Click "Sign up button"
A pop up frame shows up
Fill in foo@foo.com in the e-mail field
Fill in 1111 in the password fields
Uncheck "Yes, send me useful news about SoundCloud"
Check "I agree to the Terms of use and Privacy Policy"

Click "Sign Up"

A new tab in Firefox opens up to https://soundcloud.com/signup

Updated

6 years ago
Whiteboard: [topapps]

Updated

6 years ago
Assignee: nobody → english-us
Component: Desktop Runtime → English US
Product: Web Apps → Tech Evangelism
QA Contact: desktop-runtime → english-us
Here's the underlying problem - Soundcloud on marketplace goes off of http://soundcloud.com. Doing the signup process Jen has identified results in sending you to https://soundcloud.com, which is off the main origin. This is an evangelism bug for the developer - the platform is doing the correct behavior here.

Updated

6 years ago
Summary: [Marketplace-Beta Testing] Cannot sign up for SoundCloud → Cannot sign up for SoundCloud in Desktop WebRT - Redirects Off-Origin on Sign Up

Updated

6 years ago
OS: Mac OS X → All
Hardware: x86 → All
Couldn't we whitelist http to https urls?
(In reply to Andrew Williamson [:eviljeff] from comment #2)
> Couldn't we whitelist http to https urls?

In the short-term, I don't think we should (we have a partial solution supported, but we decided to only support https in our temporary solution for security reasons). Generally though, the app shouldn't be doing this (it should target a primary origin for the app). Can we notify the app developer about this?
(In reply to Jason Smith [:jsmith] from comment #3)
> (In reply to Andrew Williamson [:eviljeff] from comment #2)
> > Couldn't we whitelist http to https urls?
> 
> In the short-term, I don't think we should (we have a partial solution
> supported, but we decided to only support https in our temporary solution
> for security reasons). Generally though, the app shouldn't be doing this (it
> should target a primary origin for the app). Can we notify the app developer
> about this?

Its fairly common (unfortunately) to use https for login and signup but http for the majority of the content.  The current implementation means that if you have a single https page in your app then you have to serve the manifest and every page via https for it all to work, (if I understand the problem correctly?)
(In reply to Jason Smith [:jsmith] from comment #3)
> (In reply to Andrew Williamson [:eviljeff] from comment #2)
> > Couldn't we whitelist http to https urls?
> 
> In the short-term, I don't think we should (we have a partial solution
> supported, but we decided to only support https in our temporary solution
> for security reasons). Generally though, the app shouldn't be doing this (it
> should target a primary origin for the app). Can we notify the app developer
> about this?

No, we should instead fix bug 752666, which will resolve this issue by allowing the app to load a page from any origin.  It's possible that the app shouldn't be doing this, and the runtime will probably prevent trusted and certified apps from doing it, but right now the runtime only supports untrusted apps, who should be able to do it.

(For the definitions of "untrusted", "trusted", and "certified", see the draft security model <https://wiki.mozilla.org/Apps/Security>.)
(In reply to Myk Melez [:myk] [@mykmelez] from comment #5)
> (In reply to Jason Smith [:jsmith] from comment #3)
> > (In reply to Andrew Williamson [:eviljeff] from comment #2)
> > > Couldn't we whitelist http to https urls?
> > 
> > In the short-term, I don't think we should (we have a partial solution
> > supported, but we decided to only support https in our temporary solution
> > for security reasons). Generally though, the app shouldn't be doing this (it
> > should target a primary origin for the app). Can we notify the app developer
> > about this?
> 
> No, we should instead fix bug 752666, which will resolve this issue by
> allowing the app to load a page from any origin.  It's possible that the app
> shouldn't be doing this, and the runtime will probably prevent trusted and
> certified apps from doing it, but right now the runtime only supports
> untrusted apps, who should be able to do it.
> 
> (For the definitions of "untrusted", "trusted", and "certified", see the
> draft security model <https://wiki.mozilla.org/Apps/Security>.)

After the implementation of bug 752666, let's re-evaluate this bug to see if evangelism is still needed or not.
Depends on: 752666
Dependency is fixed - this should be fixed now, but will re-test to be sure.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.