I'm assuming this function has changed, moved, or been replaced? Whatever the case, when I have securepages 6.x-2.x-dev installed along side securepages prevent hijack module my site errored out.. not sure what exactly triggered it as it took about a day before the issue happened. But when it did all I was getting was a blank white screen. Before the problem I was adding a product to ubercart than nothing.

I turned on error reporting and got this--> Fatal error: Call to undefined function securepages_url() in /home/content/04/8554604/html/sites/all/modules/securepages_prevent_hijack/securepages_prevent_hijack.module on line 100

Afterward I replaced securepages module with ver 1.9 and site started to work again. Hopefully this gives you enough information to know where the bug is. For now though I'm going to uninstall 'prevent hijack'. If some changes are made that should fix this I'd me more than happy to test it out again and report back anymore problem.

Comments

orcaomar’s picture

hey,

here's a fix you can try when using the 6.x-2.x-dev version of securepages. it changes the behavior somewhat, but if your secure pages setup is right, it should be ok.

so, to get rid of the error simply comment out the violating section of code, namely comment this out in securepages_prevent_hijack.module:

if ($form['#id'] == 'user-login-form' || $form['#id'] == 'user-login') {    
    $url = parse_url($form['#action']);                                         
                                                                                
    $base_path = base_path();                                                   
    $path = (!strncmp($url['path'], $base_path, drupal_strlen($base_path)) ? dr\
upal_substr($url['path'], drupal_strlen($base_path)) : $url['path']);           
    $options = array('secure' => TRUE);                                         
    if (isset($url['query'])) {                                                 
      $options['query'] = $url['query'];                                        
    }                                                                           
    $form['#action'] = securepages_url($path, $options);                        
    }

the reason this is fine to do is because what that code does is ALWAYS secure the login form. but, you should be doing that anyway in your secure pages by matching user/login. furthermore, the 2.x-dev version of securepages seems to handle the case where you use a login block and it secures that too:

  // If the user/login path matches, also secure the login block.               
  if (securepages_match('user/login') && $form_id == 'user_login_block' && !$is\
_https) {
    $form['#action'] = url($path, array('absolute' => TRUE, 'base_url' => secur\
epages_baseurl(TRUE)));
  }

so if you still want to prevent hijacking, i believe that change should fix things up. i'd hope the author would confirm, but it doesn't seem like they are watching this bug.

WeRockYourWeb.com’s picture

Thank you!! Exactly what we needed.

astonvictor’s picture

Issue summary: View changes
Status: Active » Closed (outdated)

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