OAUTH redirect issues

[BradyR6]

Dave,

Our iPad app is now getting crashed by the final redirect in the login OAUTH process.

When did the process change?  Yesterday it was working.

I am getting the error when the redirect happens from:

http://login.constantcontact.com/login/?goto=https://oauth2.constantcontact.com/oauth2/oauth/login?r...

to

https://login.constantcontact.com/login/?goto=https://oauth2.constantcontact.com/oauth2/oauth/login?...

The only difference is the HTTPS...

Can the previous redirect go to the HTTPS instead of going to HTTP and then being directed to HTTPS?

That would solve my issue.  At this point, I will have to resubmit my app to Apple to fix the issue.

Thanks.

Brady Roberts

iCapture 

[DaveBerard]

We did do an update to our Login application for a security update on Friday.  I want to make sure I understand what you're saying is happening, here's the flow as I understood from your post:

OAuth flow is initiated from iCapture iPad app

User is redirected to http://login.constantcontact.com from the OAuth trigger request

User is then redirected again to https://login.constantcontact.com from the original login page

Some error happens in your application (could you clarify what the error is if possible?)

Will look into this as well on my test pages to see if I can reproduce the behavior as well, but please get back to me with clarification on my understanding ASAP.  If I'm missing something, the sooner you can correct me the better.

[DaveBerard]

*UPDATE*

I was able to reproduce the redirect flow you mentioned.  In fact, we do multiple redirects to clear the existing session (logout account) and then allow the user to log in.  I didn't have any problems with the redirects on my test applications.  Can you clarifiy more what the error you're seeing is on the iPad as I don't have any iOS test apps.

[JamesB8225]

HI,

   I am having a similar issue with loading CC oauth over secure connection. since we open the oauth in an iframe we get a security warning and the iframe stops loading. after looking at fiddler trace, one of the redirects is to http and then to https.  below is the sequence of re-directs i am seeing in fiddler. the last call is over non-secure connection

GET https://login.constantcontact.com/login/logout?relogin=true&wb=false&goto=https%3A%2F%2Foauth2.const... HTTP/1.1

Host: login.constantcontact.com

GET https://login.constantcontact.com/login?goto=https://oauth2.constantcontact.com/oauth2/oauth/login?r... HTTP/1.1

Host: login.constantcontact.com

GET http://login.constantcontact.com/login/?goto=https://oauth2.constantcontact.com/oauth2/oauth/login?r... HTTP/1.1

Host: login.constantcontact.com

the issue we are seeing is 

[blocked] The page at 'https://t7423.mozu-si.volusion.com/Admin/s-11039/capability/edit/fbf7481135204bcf82cfa2dd014e8316' was loaded over HTTPS, but ran insecure content from 'http://login.constantcontact.com/login/?goto=https://oauth2.constantcontact.com/oauth2/oauth/login?r... this content should also be loaded over HTTPS.

Sanjay

[DaveBerard]

Will open up a defect on our side with our login application. 

However, want to mention something we've put in other posts.  Constant Contact does not support using iFrames for OAuth flows or login flows.  Best practices for end user security around OAuth and login in general are to never have a user provide the username/password on a page that does not show the URL in the browser window.  Since an iFrame hides the URL the user is actually putting their username/password into, the user doesn't know the actual site they are sending these to.  This is a very common technique used for impersonation attacks. 

Currently we do not block iFrames from using our OAuth flow but we do not recommend or support them and may remove support for this in the future for security purposes.