I've tried different configurations, I've looked at code, I think it's a bug in Secure Pages.

The situation is I'm using Ubercart with SSL on my site but I'm using an external payment gateway, meaning mysite sends an order id and payment amount to an external payment processing site. (moneris.com) The user enters card info there and is re-directed to a page back on mysite after processing.

Ok, so the problem is when I enable Secure Pages for the checkout process and check the Action on the submit form in the review page it indicates the correct location to submit form data. https://www3.moneris.com/HPPDP/index.php but actually submitting the form brings me to https://mysite.com/HPPDP/index.php, which of course gives a 404 error.

You can see the something is replacing the domain name of the form action after the submit is pressed. I all works properly when Secure Pages in NOT enabled, so this leads me to believe it is that module.

Looking at the code, it seems to me the hook_form_alter() is checking the path in the form action, in this case /HPPDP/index.php, and sticking the base_path in there, rather than recognizing that it doesn't belong to mysite.

I'm not fully familiar with some of the functions in there but it seems like maybe all it needs is to check the form action and if it doesn't belong to my site, just leave it. If it does, THEN do the necessary checks and modifications.

I've just disabled it for now as the critical data that needs protection is handled on the moneris page anyway. But for user confidence this issue should be resolved.

Thanks for an otherwise very useful module!

Comments

rszrama’s picture

rszrama commented

I can verify this issue from others in the forums using solutions like PayPal Website Payments Standard. The work around in your case is most likely to protect the path HPPDP/index.php. This should allow it to pass through.

It sounds like your solution for the fix is reasonable, but I don't know enough about the code in SP to affirm or write a patch atm.

chayner’s picture

chayner commented

I modified the securepages.module code slightly, adding a check to see if the $host that was found in the $form['#action'] was the same as the SERVER_NAME. If it was not equal, it quit the function.

(my line numbers may be slightly off)

114  if($form['#action']) {
115     extract(parse_url($form['#action']));
116     parse_str($query, $query);
117    
118     if ($host != $_SERVER['SERVER_NAME'])
119     {
120       return;
121     }
sleepingmonk’s picture

sleepingmonk
Primary language English
Location Vancouver Island 🇨🇦
commented

@chayner: Any chance you want to submit a patch?

gordon’s picture

gordon commented
Status: Active » Fixed

Fixed in 1.7

nejcmenard’s picture

nejcmenard commented
Version: 5.x-1.6 » 5.x-1.7-beta1
Status: Fixed » Active

Hi!

I am using 1.7 beta1 of secure pages module, but the problem persist??

Any other advice?

regards2all...Nejc.

nejcmenard’s picture

nejcmenard commented

#2 mod is working in 1.7 beta1... not included?

Fixed in 1.7?? not fixed or wrong code posted?

Leeteq’s picture

Leeteq commented

Is this fixed? (should this issue be closed?)

puzzlemaster’s picture

puzzlemaster commented

I had the same issue while using the 1.7 code and tried applying 1.7 - this did not fix the problem. I applied the snippet in comment #2, and this works in both 1.7 and 1.6, so I am currently running with the "patched" 1.6 version on my production site.

gordon’s picture

gordon commented
Status: Active » Fixed

I have fixed this in both 5 and 6.

I have made the change so that it will not stuff with forms who action is pointing to an external url. This is really a bad thing to do esp. since Drupal adds a lot of other crap to the form that may cause problems on the receiving systems form processor. You may not even see the problem on the screen.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.