Consider two php scripts(o.php & t.php) o.php contains both html and php. html here gets user input for eg:user name and password this information is passed to php using php-self.

I want the user input of o.php passed to t.php without any modification in o.php.

I ve used include and require in the t.php but the problem is it displays the output of o.php but i need only the user input values from o.php without displaying the output of o.php.

Using functions or session in o.php we can pass user input but am in the situation tat i should not add or modify o.php.

thanks in advance!!

If you really cannot modify it, the best way is to create a third page, which combines the user input from the first page and the second page - this page grabs what's in the session (assume that's how you pass things around), concatenate with page two.

This can easily be done with PHP, or things like jquery (assuming not breaking same origin policy).

thanks for the suggestion but if u could explain little more with how could i combine inputs of o.php and t.php in the third page.i can get input of t.php using session but how i can get input of o.php to third page???

thanks again!

Check out f_get_contents.

Sorry:-( tats not working for me file_get_contents function reads the file and store it in a string but i want to access values in the file

$str=file_get_contents('sample.php');
echo $str;

above code displays all the statements in sample.php but i need access variables in sample.php script to another php
thanks..

Passing information from one webpage to another is difficult because HTTP is a stateless protocol. In other words, when the forefathers of the internet (not Al Gore ;) ) created HTTP to drive it, they specifically wanted to spare servers the job of carrying around a lot of information from one page request to the next. That's why we have sessions now, to make up for that lack of state. So a session is one way to keep information around, in fact it's the only way to keep that information on the server between page requests.

However, the more sessions your server is keeping track of, the more server load you're putting on it, ie sessions can seriously affect the scalability of your application. If you can use other techniques, it's not a bad idea, though by using appropriate small sessions, they are an excellent feature and very usable. Best practice is to store just a session id in your session. This is sufficiently small not to impact server performance badly and provides some limited security and error management. When the user requests a page, check to see if the session holds that session id. If not, this is the first page they've hit on the website, so assign them a session id and save it to the session and a database table. If they DO have the session id stored in the session, hit the database and you can identify them based on which user is attached to that id.

There are all kinds of identification, authentication, authorization, and security features you can add to that. But that's the basic idea for running a session. Then any other information you might be tempted to store in a session can be stored in the database, stored in XML files, sand files associated with the session can be kept in a folder for each user. The session id leads you back to the user, and you can locate all of the other information you need from the user id.

On the other hand, sometimes you want to store the information client side and pass it from one page to another using HTTP headers. You can't store a lot of information this way (at least you shouldn't), and this technique is very insecure, but it does eliminate having to keep track of anything on the server, because all the information you need to create each page is submitted with its page request.

If you use a GET, you can place the information in the URL (e.g. http://www.mysite.com/mypage.php?par...ondPieceOfData). If you use a POST you can send the information directly through the HTTP headers where they are technically invisible to the average user which affords you some additional security (however, any serious hacker can write their own HTTP headers which is why all user input is completely suspect). POST data is generally passing form fields, that's why forms typically post back to the server. However, using type="hidden" form fields allows you to save your own data (as opposed to user input) so that you have access when the form is submitted. Just remember that any serious hacker can easily modify any of these values to suit their own purposes. If security is a concern, ALL user input should be treated with the appropriate level of skepticism because in the end, GET / POST data can be manipulated at will and data in the Session can as well (because it uses cookies client side to save the session id).

__________________
-------------------------

Whatever you can do or dream you can, begin it. Boldness has genius, power and magic in it. Begin it now.
-Johann von Goethe

When Two Hearts Race... Both Win.
-Dove Chocolate Wrapper

Chroniclemaster1, Founder of www.EarthChronicle.com
A Growing History of our Planet, by our Planet, for our Planet.