Optional support for HTTPS
| Project: | Login Menu |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | rwohleb |
| Status: | active |
Jump to:
I have a number of sites (most living as sub-dir installs from a single source installation), and do not want logins to occur over cleartext _at all_.
I modified loginmenu.module as follows:
function loginmenu_menu($may_cache) {
global $user;
global $base_url;
$url= str_replace('http://', 'https://', $base_url);
$items = array();
if(!$may_cache){
$items[] = array(
'path' => 'login',
'title' => t('Log in'),
'description' => t('Log in'),
'access' => !($user->uid),
'callback' => 'drupal_goto',
'callback arguments' => $url,
'type' => MENU_DYNAMIC_ITEM | MENU_NORMAL_ITEM,
'weight' => 10,
);
}
return $items;
}
This causes the connections to /login on each site to get redirected to the site's base_url (as defined in /sites/x.y.z/settings.php), and enforces the use of HTTPS, thereby securing the connection.
I'm not sure if it's worth making an option page to allow the user to select whether to force HTTPS for logins; nor do I know how you'd do that even if you wanted to. If the above code proves helpful to anyone, that's super.
#1
This is a good idea, but we'll need to address a few things. For example, on many hosting accounts, people have access to a free HTTPS URL that they can use with their domain. Is there a way to keep the session?
#2
The session is saved. The problem is that the shared SSL certificate won't match the domain where Login Menu is being used -- and the browser will throw an error saying so -- but that's a problem inherent with using shared certificates, not Login Menu.
I really like this idea. In the meantime, I'm using the Secure Pages module for just this kind of functionality.
#3
You misunderstand. I was not referring to shared certs accessible under https://yourdomain/. I was referring to certs used through something like https://hostingcompany.com/~yourdomain/. The first would throw a warning, the second would not.