My website is using HTTPS, and I am using an iframe in which I am opening the "Authorization URL" which in my case is
I get the following error and i get a blank screen and login page is not shown,
[blocked] The page at 'https://beta.campaigns.skenzo.com/campaign/create#Choose-List' 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.
In the chrome dev tool i can see one 302 to http://login.constantcontact.com/login/?goto=https://oauth2.constantcontact.com/oauth2/oauth/login?r...
Attached is the screenshot of the same.
Thanks for reporting this. Will open a defect and look into why there is an http redirect happening during the login flow. Will update when we have more information.
Has there any solution to this issue yet ?
I'm experiencing the same issue. Loading the login page with iframe, but was blocked due to redirect to http .
No update on this. As mentioned previously, this is not a high priority for us as we recommend not using iframes for the login flow as an end user security best practice. Since we do not support this and recommend not using this flow, we are not looking at this as something we need to fix quickly. We do not have immediate plans to block iframe for our login page but it is worth mentioning our security team is aware of this and could require us to block that access completely in the future. If so, this would cause any iframe based OAuth solutions to not work.
Just ran into this also. And really need the iframe method to work as our application is a SPA we do not want to navigate away or open more tabs.
Is there any possibility of properly fixing this problem? Seems there is one redirect to http://login.constantcontact.com/login? instead of https://...
We still have no plans to address this issue. While we do understand some of the cases put forward for why an iframe flow makes sense, our security team has continued to push that this is not an industry best practice and is generally considered bad for users. Typically iframes of logins are used for phishing attacks. We do have plans to block the ability to iframe our login flow entirely and we are unlikely to fix the http redirect issue without putting this blocking in place at the same time as it would allow iframe phishing attacks otherwise.
Sorry that this answer is most likely not what people on this thread are looking for but at this time we have no plans to change our stance on iframe support for our login flow.
(Years go by...)
This is an issue on our site as well, trying to have a survey form embedded in WordPress, with all content https. With some effort, we can find an link to the survey ('questions') that stays https... but then after submitted, the response URL snaps back to http.
It seems that best practices would be to maintain the sequence in the same protocol as the request. If a process is initiated with https, it should stay https.
(Note in our case, it's not about login -- surveys proceed without a login sequence.)
Thanks for bringing this up. I do not believe this would be the exact same issue; however I will look in to this and see what we can come up with for you.