Support to pre-rewrite links to the correct protocol instead of redirect (patch)

Does this patch account for <front>? If I don't have <front> in the list of pages to secure, then $path resolves to FALSE (empty) in the second if statement, and doesn't get rewritten without https://.

"Do you mean that links to don't get rewritten back properly"

That's what I mean.

Assumptions:

• looking at https://example.com/user (or whatever I've chosen to make secure)
• the front page is the root of the site (pretty typical)
• a menu item links to <front>
• <front> is not in the list of pages to serve securely

The URL in the link is written as https://example.com/ All other links get rewritten (say http://example.com/about for example) properly.

Now with this patch, links to the <front> page not rewritten at all. That is, they are insecure if the page you're visiting is insecure, or secure if the page you're visiting is secure. The patch still works correctly for links like 'about', etc.

Will the first if statement ever resolve to TRUE? When I look at $path as passed to the hook, it appears to be an empty string when the path in question is <front>.

edit

Rerolled with:
git diff --no-prefix --relative

Awesome, works well. Fixed a bug we were having with IE not initiating HTTPS as well.

Is there a way to force http:// for the frontpage?

Update

With Boost enabled everything works fine with this patch.
Whenever a webform node is secured via SSL clicking on a normal not secured link it switches back to http://. Only the frontpage is just using the protocol where you came from...

Example:
Clicking from http://mysite.com >> https://mysite.com/webform works. If I know click back to home from https://mysite.com/webform >> https://mysite.com is still get the https on the homepage. This behaviour is only for <front> - all other urls are switching exactly as supposed to.

Is there a way to modify this patch, so that frontpage will load in http://? I am also using secure pages (of course) and is not in the selected list for SSL.

Any help would be really aprecciated - I tried already 3 days to find this trick.

Still need help with that... :-(

Support for D7 version?

Ok I wrote it by myself. The D7 version:

<?php
function securepages_url_outbound_alter(&$path, &$options, $original_path) {
  global $is_https, $user;
  if ($path == '<front>') {
    $path = variable_get('site_frontpage', 'node');
  }
  if (variable_get('securepages_enable', 1)) {
    if ($path && !$options['external'] && securepages_can_alter_url($path)) {
      $page_match = securepages_match($path);
      $role_match = securepages_roles($user);
      if ($page_match && !$is_https) {
        $options['external'] = TRUE; 
        $path = securepages_baseurl(TRUE).'/'.drupal_get_path_alias($path);
      }
      elseif ($page_match === 0 && $is_https && variable_get('securepages_switch', FALSE) && !$role_match) {
        $options['external'] = TRUE;
        $path = securepages_baseurl(FALSE).'/'.drupal_get_path_alias($path);
      }
    }
  }
}
?>

I wrote it because securepages with SWITCH back enabled was incompatible with boost module. Hope that will help someone.

-----------------------
www.ArtActivator.com - Order your success!

Can you please roll this as a patch so it can be tested easier.

Here is the code from #14 in a patch.

I have not tested it or anything, just rolled the patch.

I have done some testing of this, and there was a problem with securepages_can_alter_url() wanting external fields so it was always rejecting, since hook_url_outbound_alter() is passing an internal url (ie. node/1 or user/1)

This should be fine, but if you can check this to make sure it doesn't break anything.

I'm closing it because the issue was created a long time ago without any further steps.

if you still need it then raise a new one.
thanks