I have an e-commerce site where the login page contains a custom login form along with a fboauth based facebook connect button. Logging in through facebook only works on either HTTP or HTTPS. If we generally prefer use of HTTPS for login purposes, we have to go with that when configuring the Facebook app. For normal page requests we do however want to avoid serving HTTPS, due to heavier load, so we only redirect users to HTTPS once they hit for an example /user or the checkout process.

When Modal forms is used for login links, you will in this scenario run into issues if the user clicks a login link in the main navigation which opens the login form in a modal... and the user then attempts to connect through Facebook (which is set up to support HTTPS). Facebook's server will not be too pleased, and throws a nasty 500 internal error.

The simple solution to this is to allow administrators to disable Modal forms activation for "insecure" pages. This will send non-HTTPS users to the normal page containing the form in question - where you can have a module such as securelogin secure the form (redirect to the HTTPS version). If you on the other hand have a page which is redirected to HTTPS by default, like a checkout page would typically be, any login links (and other supported links) within that page can still open in a modal and prevent the user being redirected away from the page. It's a fairly OK compromise for anyone wanting to run mixed protocols, imo.

Members fund testing for the Drupal project. Drupal Association Learn more


hoesi’s picture

Title: Additional activation options » Additional activation option for HTTPS
Status: Active » Needs review
2.43 KB

Patch for the suggested option attached. :)

hoesi’s picture

Actually, come to think of it, Drupal 7 already supplies a global for whether or not the page is secured through HTTPS, so here's a new patch adjusted to utilize that.

hoesi’s picture

Version: 7.x-1.0 » 7.x-1.x-dev
frjo’s picture

Any one else who need this? If yes I will commit it.

hoesi’s picture

Any one else who need this?

If no-one takes the time to reply, I'd still argue that the answer is yes. Mixed mode is the most common approach to SSL (especially in e-commerce). For an indication of it's popularity, just look at the 20k or so sites using Secure Pages. It's also becoming increasingly common to offer login through a modal with the option of either creating an account/signing in the ordinary way, or log in / sign up using social media. This kind of approach is again particularly important in e-commerce, where the goal is to offer as little resistance as possible through the checkout flow. I happened to submit a patch to fboauth addressing a modal-related issue there, which several users have expressed a need for. Illustrating that it is a valid use case, in case you are in doubt. See #1364698-40: Popup / modal dialog?

In my store things work like this;

- When an anonymous user visits the site, they are served a non-HTTPS version. This greatly reduces load on the infrastructure, and also leads to shorter load times for the user due to less time wasted establishing connections.
- For an example the checkout pages are served via HTTPS (enforced by Secure Pages); here the user sees a pane where they have the option between clicking a button (themed link) to sign in or register, which opens a modal with the content of the sites login page (link being user/login), or they can enter their email address in a form right in the same checkout pane to continue as a guest instead. In order to have facebook login work in a modal here, the App (over at facebook) needs to be configured with a https:// URL.
- The site also has a login link in the secondary navigation (again, user/login).

If the user is on a non-SSL page and clicks the user/login link in the secondary navigation, the login page would be loaded in a modal. Neither of the SSL-enforcing modules (Secure login or Secure Pages) will be able to secure the content. Thus trying to auth with facebook via a facebook connect button configured for HTTPS will lead to the mentioned 500 internal error.

There's nothing unorthodox about the above approach, and login links is one of the intended uses of this module. All it takes to go wrong is mixed mode SSL, a facebook button on the login page, login links being set to open in a modal, and these login links being present on both secure and insecure pages. Disabling the modal when the user is on an insecure page should in these kind of scenarios be an acceptable compromise, because it'd automagically work as a modal on important pages such as the checkout (which is served as HTTPS)... while otherwise redirecting to the normal page/form where the appropriate redirect to HTTPS can be performed. I have this in production now, and it works very well.

I firmly believe it will be a valid/useful addition. :)

Media Crumb’s picture

Was this committed? I'd love to use this feature as well.

splitsplitsplit’s picture

I'll second that. I'm building a job site not e-commerce but the principle is the same and serving all SSL is a big performance hit.

frjo’s picture

Status: Needs review » Fixed

Committed to 7-dev. Thanks for the contribution!

hoesi’s picture

You are very welcome - thanks for the commit. :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.