execute other code in file after sending entries

[tableman]

I have the following code in separate.php passing values from form to receiving file:

form -> separate.php file -> vendor's receiving file

Code:

Code:

<?php
$url="https://receivingsite.com/receive.jsp?";
foreach($_POST as $key => $value)
{
$url .="$key=" . urlencode($value) . "&";
}
header ("Location: $url");
?>

Now I find that upon receiving the values, the receiving file opens a default page that I don't want visitors to see, and any other code in my separate.php file does not execute.

What can I change in my separate.php file to execute whatever other code I include in it?

[rdivilbiss]

Send the variable vis POST to the receiving page via AJAX, capture any results from that page and format the response however you want and show it or not as you see fit.

[CrYpTiC_MauleR]

Is that possible? I thought AJAX prevents against cross domain access otherwise someone can put AJAX request on say ERT to send AJAX request to Gmail thus being able to get sensitive information like cookie if user is logged in at the time.

[tableman]

What if, instead of using header, I pass the $url variable to the file() function thereby sending the values, but still able to execute any other code that might be in my separate.php file?

If that could work, I would appreciate some hint on how to do that.

[VGR]

classical problem. The modern solution is suggested by Rod, client-side.
I encountered this problem and solved it server-side.

You've to launch ("spawn") an other process (or thread or task or... whatever the OS is ) to perform asynchroneously the remote call and continue execution on your own. The problem is, you probably want it synchrone because you'll check the result of the remote call, right ?
in any case, you'll probably end up with a blocking call at some point, or a synchronisation mechanism (various possibilities do exist)

I humbly think I can help, if you explain a little more the code performed after the remote call, and what you do of that remote call (as you don't want users to see the remote page, cURL probably hasn't solved your problem ;-)

[rdivilbiss]

Is that possible? I thought AJAX prevents against cross domain access otherwise someone can put AJAX request on say ERT to send AJAX request to Gmail thus being able to get sensitive information like cookie if user is logged in at the time.

Yes, straight up AJAX would be a problem cross-domain...could use the widgets in Dojo to get around that.

The browser makers imposed the cross-domain policy to help against attacks like you mention and the developer community promptly developed work a rounds.

VGR will probably come up with a better solution server side.

[tableman]

I may have made this sound more complicated than it is. If so, my apologies.

I was not completely correct when I said that the other code does not execute.  Only part of it does not execute.

I place whatever other code it is (all working), ahead of the code in question.

The portion of the other code that sends an email to me containing the values from the form, still does that.

The portion of the other code that opens another page, does not open it any more.

Instead, a nuisance (to me) confirmation page generated by the vendor's receiving file opens instead of the page I specified in my other code.

This is the part of the other code that does not open any more:

Code:

print "<meta http-equiv=\"refresh\" content=\"0;URL=http://mywebsite.com/next.htm\">";

I have to send to their receiving file with the confirmation page because the regular one they designed for this purpose (no confirmation page) requires that the form's redirect field be included, and that is a problem to me (not to most of their customers) because I have two buttons in the form going to two different pages, instead of one button like all their other customers would have.

The receiving file (confirmation page) that I have to send to was designed with a different use in mind, but I have to send to it because the regular one must receive a form field that I do not want to include.

So it seems that I need to replace header ("Location: $url"); with something else.

Any suggestions?

[VGR]

I see two fast "answers" :
- you may issue your header(location) BEFORE the remote call, provided you set up the delay high enough (2 seconds should be fine)
- you can ensure that no confirmation page isn't seen by just recording the data to send to the remote server (in a table for example) and have a second process poll that list/table for remote execution with no user interaction. The results positi!ve/negative could be stored too via an UPDATE of the same table, flag "execOK" or the like.

I think this way you solve elegantly all your problems : only a short sub-minute delay is introduced.
The second process can be anything from a PHP CLI application in a crontab, a windows executable like my OuaibeRobot, just an AT command for a batch containing a PHP CLI call, etc etc
an other possibility : use an hidden FRAME (if you can use a frameset) or IFRAME (if not) running contunuously the PHP code to perform the above : read table for ne entries, perform calls, store results.
It's perhaps the best solution if you don't have access to the server at the OS level.

I'm sure other people can think of other possibilities. Stay tuned ;-)

[tableman]

Yes, they can, and I'm glad to say, they did.

As I said earlier, "it seems that I need to replace header ("Location: $url"); with something else".

Here is what other people suggested:

Code:

$array = file($url); //Reads File To Array

So now I have:

Code:

<?php
$url="https://receivingsite.com/receive.jsp?";
foreach($_POST as $key => $value)
{
$url .="$key=" . urlencode($value) . "&";
}
$array = file($url); //Reads File To Array
?>

With that replacement, the other code can now open another page, the values are sent and accepted, and the unwanted confirmation page never appears, not even briefly (as it did when I tried include("$url");).

I don't know much, but my guess is that $_POST inherently recognizes $array if its there, and so is now posting $array, so control of the browser now stays with my file instead of going to the vendor's receiving file, whereas  header() was transferring browser control to their receiving file thereby opening their confirmation page.

Is that what is happening?

[Esopo]

Hi,

I'm not 100% sure I understand your problem, but let me throw in my $0.02,

As I understand it, you are taking data received through a POST and sending it through a GET request to your vendor's script.

To accomplish this you are generating the GET URL request and then sending it through server headers using

header ("Location: $url");

What happens when you do this, is that before the HTML page even gets generated your script is telling the browser to go to the new location. If you have any HTML after that line it will probably not be executed.

Then you mentioned you want to include this line:
print "<meta http-equiv=\"refresh\" content=\"0;URL=http://mywebsite.com/next.htm\">";

Which is a meta redirect, part of the HTML content. If this code is going as-is right after the server header (location: $url) then I can see why your code is not going to execute, and even if it did I'm not sure it will achieve your purpose.

As I understand it you'd like to reach the vendor with the GET request, and then send your visitors to another page in your site. The code you proposed is fighting itself to either go to the vendor or to your site, but it will not happen in a succession.



Now, the last code you proposed, using file() to send the GET request to the vendor, should do the trick. What happens is that instead of sending output to the browser to tell it to go to the vendor's page, you are using PHP on the server side to execute the GET request and store the output in a variable ($array). Then your script can continue it's normal execution because it hasn't left.

(Is this making sense?, and, did I get it right?)

[rdivilbiss]

Now, the last code you proposed, using file() to send the GET request to the vendor, should do the trick. What happens is that instead of sending output to the browser to tell it to go to the vendor's page, you are using PHP on the server side to execute the GET request and store the output in a variable ($array). Then your script can continue it's normal execution because it hasn't left.

(Is this making sense?, and, did I get it right?)

FWIW, I think you made a lucid and correct argument.