Hi there.

basically i would like to submit a form to 2 seperate locations.

currently i'm looking at daisy chaining the submits, but i was wondering if there is an easier way to do this?

currently i'm looking at daisy chaining the submits

If by daisy chaining you mean that the first location redirects to the second location then yes.

Using whatever HTTP library you have on your target location, send a HTTP request mimicing the received request. This is basically the same as daisy chaining but the web client doesn't see it and can't accidentally on purpose interfere because they don't trust javascript.

it depends what you're trying to do and why
it may not be suitable for the second location to receive the http post from the first instead of from the client

you probably need to say why you're trying to do what you're trying to do

smells like Nigerian scam to me

it may not be suitable for the second location to receive the http post from the first instead of from the client

This is true. If it tracks the ip of the sender then my solution won't work as described unless you change site 2 to receive IP as a param rather than tracking directly. Not that that was part of the problem description.

Its a transaction site that uses the "post" method to finalise the sale on the server, but it also uses westpac which requires it to "post" to the westpac site so it can get its sales information.

given the option i would have rewritten it. but time is a factor so i have to be dirty about it

also, is it just a matter of going "target=_NEW" in the form tag to have the form post to a new webpage?

smells like Nigerian scam to me

Actually scams are more likely to use my method as it's invisible to the client except for some additional lag time if you're waiting for a response before replying(essentially a man in the middle attack).

Of course lazy scams won't bother and thats a whole couple of lines of code to do that.

Its a transaction site that uses the "post" method to finalise the sale on the server, but it also uses westpac which requires it to "post" to the westpac site so it can get its sales information.

given the option i would have rewritten it. but time is a factor so i have to be dirty about it

Aah you should have mentioned banking. I would have suggested you not f*** with it :P Daisy chaining is probably the correct option, particularly if westpac is the first hop (authenticate the transaction details on westpacs site and then westpac posts back).

Ultimately i'm going to suggest to you the same thing i suggested to my boss at australink a week or so before i decided to find less legally dubious pastures elsewhere. Don't do anything dirty with transactions. Ever. Everyone is security paranoid regarding online transactions and, unless they've changed policy, westpac requires your web service undergo verification from them so if it's dodgy it might not pass muster.

[edit] Just to make this clearer... Westpac probably has an approved way of dealing with this kind of situation since it's about as common as Hydrogen. Do whatever they expect.

also, is it just a matter of going "target=_NEW" in the form tag to have the form post to a new webpage?

will post to a new unnamed window.

last edited by Xyzzy at 14:56:26 18/Feb/08

authenticate the transaction details on westpacs site and then westpac posts back).

that was my orriginal idea. obviously this would be the best solution.

however the webpage gathers a whole host of data via sessions etc. which it then starts to transfer into a database via this "post". so its going to take hours and hours to sort through the mess and set it up properly. and as i've been paid for setting it up but are doing the "extras" for free i don't want to spend acouple of nights if i can avoid it :)

what im thinking of doing is just having the webpage process the transaction (so its logged as a processed transaction on the clients server) and then when its in that page (after processing) i'll have it open up the westpac transction site (via javascript so that its done from the clients machine) with all the transaction information.

there is the right way to do it -> which is have westpac send the reply saying "it was successfull" and processing it from there. but because the website is built in sessions then i would have to have alot of infomration sent to westpac just for it to send it back so i can regenerate the order and process. or write it to a database temporarily. but i don't really have access to the databases on that server.


like i said, there are heaps of better ways to do it. but without hacking the crap out of the original webpage (and without an "offline / test" environment) the dodgy method is probably my best bet.

last edited by myWhiteWolf at 15:24:47 18/Feb/08

http://www.php.net/curl

not really what im after as the user has to put their own CC information into the westpac page. so i can't just do it all for them. i need to just open the page and send out the right sales information so they can then make the payment using westpacs util

Did you take on the job Le Infidel posted about? Interesting.

built in sessions then

I'm assuming sessions via cookies? Assuming you require cookies(and don't use the no-cookie session hacks), you don't even send westpac anything. It's all contained in(usually) a file server side waiting for someone with the right cookie to hit the site again.

and without an "offline / test" environment

There's the killer. Not having a test environment is unfortunate.

I'm assuming sessions via cookies? Assuming you require cookies(and don't use the no-cookie session hacks), you don't even send westpac anything. It's all contained in(usually) a file server side waiting for someone with the right cookie to hit the site again.

Hacky sessions and NO, westpac receives the sales data via the Post method.

Hacky sessions and NO, westpac receives the sales data via the Post method.

I didn't actually mean the data that westpac directly needs. What i mean is that things like what the user's username is and what they ordered and where they want it delivered would be stored on your server in a session data area, not sent through westpac(the exception being the hacky session id for those who have disabled cookies).

Re-reading my post made it seem vaguer than I thought at the time.

I've dealt with a number of bank gateways, and they always have a few fields that you pass to them, that they pass back to an 'exit' page on your site when processed. These fields just need to contain a session ID of some sort that you can use the reget stored information about their purchase.

Like i said, there are heaps of better ways to do it. but without hacking the crap out of the original webpage (and without an "offline / test" environment) the dodgy method is probably my best bet.

i ended up just forwarding the page using javascript after its finalised the sale.

if they have javascript disabled or don't have redirecting enabled it could cause problems. but it looks like its working fine now.