• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 238
  • Last Modified:

Code not working after server move

Hello,
I was unfortantly caught in the Valueweb SNAFU (they crashed multiple servers durning a move).  So I am trying to bring my site back up on a new Linux server (hosted by server beach) from a backup.

I have all of the files up, but some of my forms are not working.
The form:
www.visailing.com/gail
Calls to the DB and populates the boats (so that works fine) but when you hit the submit button, the next pages loads with no information.  So it looks like my POST didn't work.

Is there something I need to set up on the new server to get that to work?
Thanks
0
CyberRazz32
Asked:
CyberRazz32
1 Solution
 
dave4dlCommented:
is the web request (POST) actually including the info it should?  Use wireshark to capture the web request if you are not sure (http://www.wireshark.org/download.html).
0
 
etullyCommented:
The problem is that the old web hosting company had register globals turned on.  The new place has them turned off (which is a good thing).  Turning them off helps improve security.

As a quick fix,  you should add this line of code to the top of your scripts:

foreach ($_REQUEST as $k=>$v) {$$k=$v;}

This will get you back on your feet again.  Then you should learn why people turn register globals off...  then you should learn about how to correctly program in an environment where register globals are turned off.  You should do that sooner rather than never but in the meantime,  the foreach command above will get your code working again.
0
 
jentulmanCommented:
The above command will as stated get you going again, but opens a security hole in your page.

Say I knew or guessed that your script used a variable called $valid_user and checked to see if that variable was set to true to allow something to happen. With the above fix, all I need to do to "inject" that variable into your script is to save a copy of the html for the form and edit it to include a field called valid_user with the value true before submiting it.
This may seem to be trivial, but it can create huge holes in your sites security and is exactly the reason that register_globals should be, and often is, turned off for shared and production web servers.
Never trust the data coming from a form or rely on specific values to be coming from it, always validate the data is of the type you expect and within any necessary numerical bounds.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
MasonWolfCommented:
register_globals is not in itself a security hazard, provided you initiate all your variables before you try to use them. PHP allows you to get away with querying a non-initiated variable and will simply return 0 or empty. So for instance, this code here would be a risk if register_globals were turned on, and is the reason why PHP5 has them turned off by default:

if(logged_in())
{
    $has_access = true;
}
if($has_access)
{
    include("/really/secret/stuff");
}

So anyway, as long as you're careful while developing, turning register_globals back on is no security risk. If you're not willing to be careful then I just hope you don't have anything too sensitive to protect.
0
 
MasonWolfCommented:
While I appreciate the points, I was merely contributing my .02 to the discussion about register_globals being a security risk. I believe etully deserves most, if not all, of the points on this question because he correctly identified the problem and provided a workable solution. If you solved the problem by turning register_globals on (which I realize is a much much faster fix than going through all your scripts to find out which ones were affected and modifying accordingly) then more power to you. But I was not the one to realize that this was the most likely cause of trouble. It makes sense, but again, etully was the one to point it out and deserves the credit. I merely explained why register_globals was a security risk and what can be done to program securely even when it's turned on.

@ etully,

If you can flag a monitor to stop by, I willingly relinquish my points to you.
0
 
etullyCommented:
MasonWolf:  Thank you for the nod.  I don't care as much about the points as I do the nod.  :)
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now