Re^2: Sending information via HTTP "POST" without submitting a form

[jeyroz]

Thanks for the response Jellyfish!

I previously looked into LWP as a solution (and will again) but ran into a problem in this instance. I don't want to post the informaiton and gather the response (for display on my server), I want the user (the person submitting the data) to be able to continue with the payment process (additional form inputs) on the gateway's server.

Does that make sense? Am I missing something?

[jhourcle]

What you're explaining doesn't make sense to me, based on what I've had to do before with passing control between systems. I'm guessing that the payment processor most likely has suggestions on how to use their system, and if they think the scenario that you are explaining makes sense, that they would have instructions for doing it.

[jeyroz]

jhourcle, thanks for your reply.

The payment processor simply expects a form to be submitted with payment information. The client has asked that we verify some "Terms of Use", etc. before their customer remits payment. We are validating their 'acceptance' of the Terms with javascript but would like backend validation as well (for obvious reasons). As you would expect, the payment processor doesn't offer validation of non payment information on their system ... therefore I am left to validate these elements once the form is submitted but before the request is sent to the payment processor. After our validation is complete the information and the user need to be redirected to the payment processor's server to complete the transaction. I would like to transfer this info via POST instead of GET as would be the case if I attached the information to a redirect like so: $q->redirect('processor_server?info=foo&info2=bar').

If this is still unclear please let me know.

[jhourcle]

It's clear -- but I wouldn't normally want to pass control of the user's session to another server.

You're right, in that you do not want to do this with GET. In fact, you should never send anything sensitive in the URI, and should never use GET for something that might have side-effects. Modifications should be reserved for POST (or PUT or DELETE, but most servers don't implement it)

Redirection in general is a tricky thing when you're trying to force someone to post. The HTTP spec specifically warns browser authors about how they're supposed to handle redirection.

From what you're describing, I would probably have the user first go to a page for them to look over what it is that they're ordering, and on that page, populate a number of hidden fields, and have then click a subtly-disguised submit button that sends them to the alternate server in question.

I still don't like giving them control, though. Perhaps set a TARGET on the form submit, so it comes up in another window, or something.