| Project: | Domain Access |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
I'm not sure whether to consider this a bug report or a feature request, but here it is: Currently, for each domain configured, you may specify whether to use http or https, and if a domain source is configured, URLs throughout that site (including form actions and so forth) use that protocol.
This doesn't entirely support my configuration. We have a public domain for our public website that uses http in most cases, but enforces the use of https for certain paths (the user login page and the admin pages) to protect this data.
Unfortunately, configuring the URL scheme for this domain to be http:// and simply letting our rewrite rules redirect to https:// does not work. Since the form actions are all set to http:// with this configuration, form submissions from https:// fail.
The solution would be one of the following:
- Allow both http and https on a given domain, and write URLs to one or the other depending on the request or base URL (using the dynamic base URL in #633726: Include instructions for altering $base_url), or
- Allow certain paths to be configured to use a separate protocol from the domain's main protocol. (This solution would be even better because it would reduce the number of rewrite rules needed to support such a configuration.)
Comments
#1
It's a feature request. You may have to handle this yourself for now in a hook_form_alter().
#2
Thanks for the quick followup. Which module's
hook_form_alter()would I need to modify, domain.module or domain_source.module? If I get it working, I can submit a patch.Edit: just to clarify, I looked at both functions, but I couldn't figure out why the form actions were all ending up as http for all forms; domain_source only seemed to be acting on the node form and "domain_content_form."
Edit 2: Never mind, I think I found it; I was looking at a hook_form_FORM_ID_alter() before. Looks like
domain_form_alter()is the function I'd need to change, theif ($seo)part?#3
Also, I think #368805: Domain Access with Subdomains and SSL was caused by the same base issue.
#4
Don't alter my function. Write your own module, something like domain_ssl. And use domain_ssl_form_alter() to change the $form['#action'].
#5
Here's the beginnings of such a module, in case anyone else is interested. (It's for 6.x, since I don't have any production 7.x sites, but it'd be straightforward to port). Edit: the files with names ending in ~ are just backups I forgot to be delete and can be removed.
All it does for the moment is fix the form action to accommodate both protocols for a domain, regardless of how the protocol gets set. It would be more useful if it implemented
hook_domain_source_alter()(I think?) to allow per-path protocol rules (e.g., use https for user/*, admin/* even if the domain is configured for http).Thanks for your help. :)
#6
Subscribe. Will look into it soon, as I need it also.
Would this be a separate (sub)module?
If so, could make a d.o project so those interested could test it and file patches, etc.
#7
I suppose that depends on whether agentrickard thinks it would be worth including with the main module. If not, I'd be glad to help maintain it as well.
#8
Subscribing.
#9
For D7, I have the following module already on my plate, but nothing for D6. Decide based on that.
DOMAIN PATH
-- Allows the registration of arbitrary Drupal paths (either aliases or canonical paths) with a given Domain.
-- Will allow rewrites of links to that path to follow the domain rewrite rules currently used by nodes.
It would be pretty easy, I think, to add an HTTP / HTTPS toggle to these settings.
I just looked through the D6 code to confirm, using either hook_domain_source_alter() or hook_domain_source_path_alter(), you can toggle the HTTP / HTTPS element of a node or Drupal path without any changes to the core module. You just have to alter the 'path' element of the $domain array by reference.
So, something like:
<?phpfunction mymodule_domain_source_path_alter(&$source, $path) {
Always write admin paths to HTTPS.
if ($path != 'admin') {
return;
}
$source['path'] = str_replace('http://', 'https://', $source['path']);
}
?>
This part is dead simple; the harder part is a UI to control these settings. A separate module is the only option for D6.
There will, of course, be a performance hit here, especially if you have to do a database lookup inside this function. Might be best to cache all the rewrite rules from a single query.
#10
+1
#11
#12
I installed the SSL module per #5. It works but with a hitch. I'm now getting the mixed content warning in IE and FF.
#13
Subscribing - would be great to have, and I'm willing to test
#14
Since this is in development for D7 but not D6, I'm going to open a new project for D6, starting with the module from #5. I'll post the link here once I get it in CVS.
#15
How does a shopping cart (e.g., Ubercart) handle something like this? Normally you would want the catalog (public material) to be http, but admin and sensitive customer information (name, address, phone, payment details, etc.) to be https. Does Drupal really require the whole site to be one or the other, but not a mixture of http and https? That would be horrible! Anyway, if Ubercart permits a mix, perhaps you could get some ideas poking around in its code?
#16
Re: #15 -- To clarify, the issue/project is specific to the Domain Access module. Drupal by itself is agnostic in that regard; it's up to the webserver to control that functionality. I've used mixed http and https with Drupal for years and it's worked fine; it's just that the main Domain Access module does not support that configuration at present. Thence the companion module.
#17
Project page:
http://drupal.org/project/domain_ssl
The module is now available in CVS, and (edit) the development snapshot is now available for download.
#18
Nice, but looking at the code, I wonder if we should just patch the main module. This is the part that interests me:
<?php
// Protocol of current request.
$req = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on')
? 'https' : 'http';
// If the protocol doesn't match the current page's protocol, fix it.
if (($action['scheme'] != $req) && ($action['host'] == $domain['subdomain'])) {
$form['#action'] = $req .'://'. $action['host'] . $action['path'] . $action['query'];
}
?>
We may want to put that into hook_domainload(), in fact, to dynamically force HTTPS in cases where other modules use the protocol.
#19
On some servers, $_SERVER['HTTPS'] may have a value of '1' instead of 'on'. You may want to check for that.
#20
Yes, I second that, I'm used to a TRUE/FALSE response. There are actually places in the code where I do this:
<?phpif (!empty($_SERVER['HTTPS'])) {
$scheme = 'https';
}
?>
See domain_set_primary_domain().
This is the proper check, see http://php.net/manual/en/reserved.variables.server.php
'HTTPS'
Set to a non-empty value if the script was queried through the HTTPS protocol.
Note: Note that when using ISAPI with IIS, the value will be off if the request was not made through the HTTPS protocol.
If the value is ever set to the string 'off', this is a server-level implementation error.
#21
Ah... well.
Would you backport it to 6.x if you patched for #18?
I actually based the protocol check on http://drupal.org/node/217710#comment-718517 (also agentrickard's post), which is what I use in my settings.php. I can patch my module to use
!empty(). However, am I to undertand from the pulled quote that this may fail on IIS? If so, maybe:<?phpif (!empty($_SERVER['HTTPS'] && ($_SERVER['HTTPS'] != 'off'))
?>
#22
Also, I've seen talk of putting something to use https for sensitive form actions in core, but looks like it didn't make it into D7: #616744: Add a UI for if the site supports https
#23
The old code sample is, well, old (from 2008). And replaced by better understanding of the PHP docs.
I would patch this directly in 7.x and then backport immediately, yes.