This is G o o g l e's cache of http://www.ubercart.org/forum/1477/ubercart_submitting_paypal_wps_form_i... as retrieved on Aug 2, 2007 23:59:35 GMT.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
This cached page may reference images which are no longer available. Click here for the cached text only.
To link to or bookmark this page, use the following url: http://www.google.com/search?q=cache:CacD_IUVrCsJ:www.ubercart.org/forum...

Google is neither affiliated with the authors of this page nor responsible for its content.
These search terms have been highlighted: 07 24 2007
Ubercart

* Home
* Documentation
* Forums
* Issues
* Livetest

Home » Forums » Ubercart » Development
ubercart submitting Paypal WPS form to itself bug
Submitted by david on Wed, 07/18/2007 - 18:51
david
Posts: 46
Joined: 05/30/2007
Bug KillerGetting busy with the Ubercode.

I am trying to use paypal website payments standard to submit a purchase from the cart/checkout/review page, and the form action is pointing to the local site, and not paypals site.

Oddly enough i can dump out $form['#action'] right in function uc_paypal_wps_form() and it shows the correct paypal URL there (https://www.sandbox.paypal.com/cgi-bin/webscr).

But when i view the HTML source of the cart/checkout/review page i see this.

what the heck? this ones got me stumped. anyone know what could be causing the form action to freak out like that? It works just fine on another site i setup WPS on yesterday, i just dont understand and im tired and need a beer.

* Add new comment

permalinkThu, 07/19/2007 - 08:22
Ryan

Posts: 1685
Joined: 09/26/2006
AdministratorCode Monkey Head - I eat bugs.

Diagnostic time... hmm... I don't know. Sticking out tongue

Can you try adding in the following after line 101 and seeing what the HTML is set to for the form?

EDIT: also see my last comment in the other thread

* reply

permalinkThu, 07/19/2007 - 09:56
david
Posts: 46
Joined: 05/30/2007
Bug KillerGetting busy with the Ubercode.

$form['#suffix'] is empty.

Shutting off secure pages fixes the issue. Don't know why I didnt think of that. If I have some time later ill look into getting secure pages to not break this.

* reply

permalinkThu, 07/19/2007 - 09:58
Ryan

Posts: 1685
Joined: 09/26/2006
AdministratorCode Monkey Head - I eat bugs.

"Don't know why I didnt think of that."

I think you already nailed it...

"i just dont understand and im tired and need a beer."

Moral of the story? Perhaps we should bring our beers to the office for coding. Evil
(I wonder if that's what the "juice" here is really supposed to be... Andy?)

* reply

permalinkThu, 07/19/2007 - 10:08
Andy

Posts: 256
Joined: 09/27/2006
Administrator

"Negative Ghost Rider, the pattern is full."

* reply

permalinkThu, 07/19/2007 - 18:18
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer

fwiw, i'm planning on using WPS myself. If i recall from looking at the documentation awhile back, for WPS, SSL is handled completely on the paypal side server. thtat's one of the benefits of using it. it allows store owners to NOT have to worry about the config.

which means the local server that uc is running on does NOT need ssl itself.

which begs the question why are you using the securepages module for WPS?

i've never used it before but i think that's for routing url requests to SSL specific urls on your own LOCAL SERVER implementation.. right?

Now if you were using PP Web Payments Pro, then i think you WOULD need to be enabling SSL on your local server and possibly secure pages as well because the customers ARE passing secure info from their browser to YOUR site and NOT directly to PP.

SUGGESTION:

i'm no SSL expert, but i've just seen a number of posts today related to both uc payment and shipping where code is breaking because of the use of secure pages. and so it appears there might be some confusion out there about SSL, securepages and the like. meaning that the problem may not be with UC but store owner server configs and understanding what a web service account requires to work (e.g. paypal, usps, ups, etc).

Something tells me that a user guide page regarding SSL would be quite useful: It would clarify:

- what a certificate is, where to get one, why you need the thing
- when you need it
- when you don't
- what uc modules (generally are going to) require it
- how to check if it's running on your currentl localhost
- how to install/configure the thing (that might be asking a little too much considering the flavors of linux that are out there)
- how securepages relates to this
- and a topic i recall seeing here in the past about having a dedicated SSL certificate versus a shared one for all domains on a box and the pitfalls of using a shared one

I know that's a lot of info and some of it falls under the topic of RTFM Eye-wink. But some of those specifics should probably be covered and others can be generalized (maybe with an external link or two) so that store owners at least have an idea of where to search to RTFM Eye-wink.

I'd write the thing myself but i've never actually dealt with this in the real world so am probably not a good candidate for it. And i'm going to be handling my SSL stuff via webservices with a provider e.g. PP WSP so i don't have to worry about SSL on my server which is the easy way out Smiling

Also, I hate to sound like i'm telling somebody to do something. The above is simply a suggestion Smiling

* reply

permalinkThu, 07/19/2007 - 20:18
david
Posts: 46
Joined: 05/30/2007
Bug KillerGetting busy with the Ubercode.

Very good post. I agree on all points.

I would like to add that explaining the difference between having apache with SSL + the securepages drupal module, and having a PHP install capable of sending SSL requests to a payment or shipping gateway is important. They are not the same thing. Sometimes you need both, sometimes you just need to ensure PHP can do SSL with the phpinfo() function, and sometimes you just want to have SSL between your server and the users browser via securepages module and a web server with SSL.

I can see there would be alot of folks out there that dont know the difference, or that there even is a difference. And alot of tech support folks who also dont know the difference, sad as that may be.

In response to why use SSL with Paypal WPS? well, maybe you just want to advertise that your checkout process is secure, since that is a buzz word, and most shoppers arent going to understand what it really means, but you are correct, there is no need for it.

The only reason we had securepages setup on that site was because we were planning on using Paypal WPP or authourizenet at first, but just wound up using WPS. And we may still want to setup several options for payment.

All in all having clear and useful documentation on payment gateways, shipping gateways, encryption and server/PHP requirements is a MUST for ubercart to grow into something that anyone can use without having a professional level of knowledge on those subjects.

* reply

permalinkFri, 07/20/2007 - 08:13
Ryan

Posts: 1685
Joined: 09/26/2006
AdministratorCode Monkey Head - I eat bugs.

Totally agreed on the documentation. I don't think I've documented anything about the payment system in the user's guide as of yet. That's partly because I was still working things out and now because I'm putting it off. Eye-wink

I don't know much about SSL, though, so anyone who has time to write pages like that is more than welcome. I setup a category in the Site Enhancements Tips section on securing an Ubecart site.

* reply

permalinkTue, 07/24/2007 - 01:08
IX
Posts: 24
Joined: 07/13/2007

I have come across the same problem as mentioned in the original post, and was able to fix by turning secure pages mod off....

HOWEVER... I was told to use SSL/secure pages mod for UPS shipping stuff... so how can I use it for one and not the other? Anyone been able to fix this matter which keeping your site "secure"? It may not be necessary for PP, but it will be for Authorize.net (which we plan to make available soon). How can we make both available in the future if one needs secure pages on, and the other needs it off?

* reply

permalinkTue, 07/24/2007 - 01:20
torgosPizza
Posts: 32
Joined: 07/05/2007

This is not something I have gotten to yet (I am modifying some UC code for my own site among other things) ... but here's what I know about getting to the Secure site without the use of Secure Pages.

Remember this is for Linux, since that's what the majority of sites running PHP are running. All it would really take is a modification that, during the transition to the checkout pane, would detect what port the browser is connecting to. Normally, and as long as ssl is supported by apache (most default configurations are), you can use port 443 for secure connections. So the code might look something like this:

if ($_SERVER['REMOTE_PORT'] != 443){
header("Location: https://www.example.com");
}

Offhand I'm not sure if 443 should be in quotes or not. This code will redirect the browser to the secure site if they are not already there.

Installing a secure certificate is a fairly painless process. It's made easier if you are using a control panel such as Plesk on a Dedicated Server. Shared hosts make it even easier, such as GoDaddy.

Essentially, what I would suggest is to modify the code in UC to go into secure mode when "Checkout" is hit, and then, once the order is completed, they can be taken out of secure mode again (as long as there is no sensitive info on that screen). This could most likely be done in another module, but I think for conciseness, modifying the UC core is probably your best bet.

* reply

permalinkTue, 07/24/2007 - 04:21
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer

i'm no expert on this ssl stuff.. but i thought you could NOT run SSL on a shared host. And IF you did, the only way you could do it is if you're using IP based vhosting and NOT name based vhosting.

So how in the hello are you getting that functionality with GoDaddy. And more importantly.. how and the hello can anything with godaddy be simple Eye-wink... read on at your own peril..

OFF TOPIC RANT on godaddy.

i just renewed a bunch of domains with godaddy on sunday. what a bunch of hucksters these guys are. the most confusing renewal + add new domains checkout i've ever seen in my life. they automatically set more expensive options on renewal that you didn't have set initially so that have to painfully disable and resubmit the form over and over again for every single domain they change the options on. They use javascript to collapse your domains and group them in idiotic ways so you can't figure out what in the hello you're renewing. they send you umpteen million email coupons that usually have no value by the time you read through all that spam and then only allow you to use one at checkout time so you have to jump through 5 hoops with a flaming donut in your mouth doing backflips to figure out which is the best deal. more time wasted. suprise surprise, those first year free private domains ain't free anymore which means i almost shatted in my pants when total domain fees doubled this year. And to boot, they have an ad right on the front page that said 5 or more new domains get free private registration and they charged me full price for them. If i hadn't scrutinized the crazy order form which was harder to decipher than the rosetta stone (and i assume many other couldn't or didn't), i wouldn't have caught it! that's an extra $35 in their pocket and out of my wallet.

I think i'm going to start a new website: "godaddy sucks pickle". What should've taken 5 minutes took way too long. They do everything in the world they can to make it hard for you to figure out what you're doing so they can make more money off you. That's not hip. It's not smart bizness savvy. It's uncool. Total classless act.

After perusing at their DNS setups i can't wait for that fun to begin.

If any body else uses a decent Registrar that offers domain privacy, send em forth and your cup shall spilleth over (in good karma that is).

Sorry for the rant but you DID mention godaddy Eye-wink

* reply

permalinkTue, 07/24/2007 - 12:32
torgosPizza
Posts: 32
Joined: 07/05/2007

I agree, their interface is messy and clunky, disorganized at best. But for a company or individual on an extreme budget (and not caring about tons of traffic) their shared solutions are decent for the price. And you can purchase shared SSL that will work with your account.. they offer it as a package, I believe. We currently run a dedicated server from them, so we have control over pretty much every aspect of our server. If you're at all serious about hosting, dedicated is the minimum direction you should take.

As far as registrars go, stay away from Network Solutions. I like them less than GoDaddy. Heard good things about register.com, and I have used Dotster in the past without any issues. Stay away from anything that claims to be "dirt cheap" - like all things in life, you get what you pay for. However also keep in mind that you shouldn't pay more than $20 a year at the absolute most for a domain. Even $15 is pushing it.

If you have other questions let me know... I'm not an "expert" but I've had to deal with stuff for quite a while now. Always a good time.

* reply

permalinkThu, 07/26/2007 - 05:34
david
Posts: 46
Joined: 05/30/2007
Bug KillerGetting busy with the Ubercode.

back on topic ... sorry for the long wait ...

the problem is that securepages rebuilds the action of the form using the current HTTP_HOST + the path if the path (cgi-bin/webscr in my case) does not match the list of pages setup in the securepages admin settings.

the way to fix it is to add cgi-bin/webscr to the list of secure pages in the securepages admin settings.

this will affect any form on a secure page with securepages module that leaves your site when you click the submit button, but can be resolved by adding the path of the off-site service (without its URL) to the secure list as mentioned above.

payal website payment standard is the only one i know of for sure that is affected, but i have not tried any others, authorizenet would not be affected since it submits directly to your site, and the authorizenet module handles the talking to the payment gateway behind the scenes, effectively never leaving the current site. paypal website payment pro is not affected since it is also done behind the scenes in the module code without needing to leave the site.

none of the shipping quote modules should be affected by this problem.

* reply

permalinkThu, 07/26/2007 - 07:46
Ryan

Posts: 1685
Joined: 09/26/2006
AdministratorCode Monkey Head - I eat bugs.

Brilliant! Thanks for researching this for us. We should make sure to stick that in the secure pages docs here when we get around to it. This will affect payment services 2Checkout.com and WonderPay as well. Good work. Smiling

* reply

permalinkThu, 07/26/2007 - 07:52
cosmo83@drupal.org

Posts: 47
Joined: 05/22/2007
Bug FinderGetting busy with the Ubercode.

I saw this yesterday and got disturbed badly. Thanks for researching on this

* reply