|
|
Posted by C. on 03/01/07 21:33
On 1 Mar, 05:35, Michael Vilain <vil...@spamcop.net> wrote:
> I setup credit card charging with a combination of php and perl. It's
> running on a shared server, so I had to use a protected perl script with
> the constants like passwords and hash keys in the script. The script is
> run by CGIwrap under my account's UID rather than as the web server's
> UID.
>
I can't imagine what problem this sensibly solves. What is a
'protected' perl script? I assume you mean with different permissions
on ownership, and running under a different uid. If the POST is
initiated by the CC handler, then there's no need to store passwords
in order to receive it.
> Perl seems to be suited to do SSL submissions to authorize.net, receive,
> and process their reply.
Why?
> Paul Furman <p...@-edgehill.net> wrote:
>
> > I'm setting up credit card payment through authorize.net and they have
> > the option to send a POST string back to my site once complete. I'm not
> > sure how to proceed. They don't have much to read about this, their tech
> > support seemed to think I've got the general idea though & said I might
> > have have my hosting server set up permissions to recieve POST data that
> > way.
I can't imagine why a hosting company would not allow POST by default.
Why not test it for yourself - just write a form with a POST method
and fire it at your PHP script.
> > So best I figure I'm going to get a redirect to my server And I'm
> > guessing I'd use something like this:
>
> > if (isset($_REQUEST['x_response_code'])) {
> > //then finalize the order, subtract from inventory
> > // and generate a reciept
>
No, you need to validate the origin of the request. How do you know
this came from the CC handler? You should also be checking that its
'1' and not anything else. Also you might avoid some CSRF by checking
$_POST instead of $_REQUEST.
> > And I'm not so comfortable with the idea of setting up a page on my site
> > that lets any external server send POST data & retrieve customer's order
> > details.
That's exactly right - you don't want to let ANY server see an order.
You valid the remote host as the CC handler and tie the request back
to a session that the customer initiated. You make hard to predict the
token used to identify the order.
C.
[Back to original message]
|