Problem with i18n/improper redirect

Hi ptmkenny ,

I've exactly the same problem between securepages and i18n modules.

I need secured login and secured admin pages but I don't want https for the rest of my site. I've founded securelogin module but it's not for mixed mode like I need. I've pulled back to drupal 6 because of that !

I'm willing to know if anyone find a solution to do mixed ssl and non-ssl before securepages modules 7.x is stable.

Same problem here!

- http://example.com/user correctly goes to https://example.com/en/user
- but http://example.com/en/user gets redirected to https://example.com/en/en/user

This makes 'Secure Pages' useless on multilingual sites -> priority = major

Has anyone found a workaround for this issue?

Thanks for the report. The 7.x branch should be fixed with 96e5a6c23e.

Moving to 6.x branch - there are possibly locale issues there too. The tests at least need to be ported.

There is also problem with securepages_form_alter. I've made workaround, but I'm not sure if it's the real fix for that problem.
I've put:

    // Remove the language prefix from the path.
    if (!empty($language_url->language)) {
      $url = substr($url, strlen($language_url->language)+1);
    }

just after:

   // Remove the base_path, and extract the path component.
    
    $url = substr($form['#action'], strlen(base_path()));

I was trying current 7.x-dev version, an problem still occurs, I was unable to disable secure page switch, or uninstall module, because I still get message of Page not found, because language prefix was doubled to sk/sk/ (slovak).

Co currently not usable for any installation used language switcher with path prefix (probable works well on domain language switcher like de.example.com) etc.

6.x-2.x branch has basic support for locale now: 639a163.

It looks like the form_alter still needs some work.

This one is brutal, and currently no way to do this without hacking the module.

It would be nice if this could be fixed properly and not something I have to keep a hack on or patch on... :)

Note you should use $language_url->prefix, not "language" as "prefix" is the actual attribute that is in the URL :)

I recently updated this module to the most recent dev release and still have the issue where forms are concerned.

If i were updating a node with a language prefix, the `Save`, `Preview`, and `Delete` buttons all referenced the node with the language prefixed twice.

I had posted a fix to this over in http://drupal.org/node/1137248 roughly a year ago, but I've found the below modification to securepages.module works just as well.

<?php
function securepages_form_alter(&$form, &$form_state, $form_id) {
  global $is_https, $user, $language;
?>

and here

<?php
  if (isset($form['#action']) && securepages_can_alter_url($form['#action'])) {
    
    // Remove the base_path, and extract the path component.
    $url = substr($form['#action'], strlen(base_path()));
    
    // Filter out any language prefixes as it will be automatically added to the URL again.
    if(!empty($language->language) && preg_match('/'.$language->prefix.'/', $url) > 0) $url = preg_replace('/'.$language->prefix.'\//', '', $url);
    
    $url = drupal_parse_url($url);
    $path = drupal_get_normal_path($url['path']);
?>

Hope this helps.

*edit: this will cause problems if you have aliases with the same name as a language prefix...

Thanks a lot for this moridin380. You've made my day!

6.x-2.x-dev exhibits the same problem (doubling language prefixes on a i18n enabled website).

Can the fix in #8 be applied to 6.x-2.x-dev without breaking anything?

Yes it works!

And with 6.x-2.x-dev, I have the authenticated role always redirecting to https, regardless of path rules. This is great news - and solves all my issues with 6.x-1.9. Here is the code from #8 revised for 6.x-2.x-dev.

<?php
function securepages_form_alter(&$form, &$form_state, $form_id) {
  $is_https = securepages_is_secure();
  global $user, $language;
?>

and the second part of #8 is good to go as is.

The regex needs to be amended so it's more specific. I've incorporated this patch, with an amended regex, here: #1647754.

moridin380, thanks you!

This patch fixes the issue. It is based on the code in comment 8.

Small update in the previous patch. (Improved Drupal coding standard compliance).

The patch in #15 worked for me. Resolved my issues with multilingual URLs and secure pages.

Hi,
This patch works for me too.
Can it go into the new version, as I patched by hand forgot about it, updated, and patched again.
Works fine here.

Cheers.

I too can confirm #15 worked for me (although I did have to apply the patch by hand as it would not apply to the latest version of the module using patch or git apply).

EDIT: this patch doesn't quite work. I was editing the /admin/appearance/settings and it redirected to /adminappearancesettings.

https://mydomain.com/admin/appearance/settings works for me. Secure pages 7.x-1.x-dev (datestamp = "1337776854").

I would try repatching - very slowly. :-)

patch #15 worked like a charm on Secure Pages 7.x-1.0-beta1 !!

Hi,

Thanks for this patch #15 that worked for me too.
But I then ran into the same issue as @webdrips. It occured on a fresh install when I was only using one language.

I updated the patch to fix it, it now works correctly, wether on multilingual site or with only one.
The patch was first testing $language->$language instead of $language->prefix, and I also updated the regexp to look for the prefix only at the start of the URL.

I experienced the problem that action paths in forms (such as the user login form) had a duplicate language prefix (in my case "/de/de") which led to the problem that the form data was sent to a page that didn't exist and caused a 404 error. But this only happened when the option "Switch back to http pages when there are no matches" was activated in the settings of the secure pages module.

The patch from #21 (manually applied against 7.x-1.0-beta1) seems to solve the problem. Thanks.

#21 seems to work as expected on beta1. Thank you!

I don't use i18n for anything, so once everyone is happy with this page please mark this issue as reviewed and tested by the community and I will commit it.

If everyone agree, I'll set RTBC. If not, please revert!

Thanks, this has been committed to dev.

If we can get this backported to 6.x would also be great as well.

Thanks everyone.

Here it is for D6, also including the fix from #1376798: Form actions aren't properly altered to http/https when the site is installed in a subdirectory

Applied patch from #29 to 6.x-2.1 (2013-Nov-10 ). Works for me. Thanks caktux!

#29 @caktux. Thanks for this, can you please split your patch up so that I can commit and test separately.

Thanks
Gordon.

While trying part of this patch for another similar use case, I noticed the >=0 when checking the preg_match result.
Was that intentional? shouldn't it just be:
if (!empty($language->language) && preg_match('/^' . $language->language . '/', $url)) {...

Also, I would suggest this instead:

if (!empty($language->language) && strpos($url, $language->language) === 0) {
  $url = substr($url, strlen($language->language));
}

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