Form Input Won't Post/Update to SQL Database

[surfcity]

I have a script which worked on another hosting platform but will not work with x10hosting. Forms within the script are used to create new users, etc. that post and update to the sql database. Currently, the form shows on the page along with the button to post/submit. What should happen is an update to the sql database then a message on the page stating that the new user was created, etc. etc. Right now, if the form is filled out and the submit button is clicked on, the page refreshes but returns to the original "fill out the form page" and no updates to the database. Assume it is something like a setting specific to this hosting platform because as stated earlier, same exact script worked on another hosting platform without any modifications to it.

 

[caftpx10]

Have you tried running the MySQL queries having issues in phpMyAdmin? That should state what the issue is.

 

[surfcity]

Thanks for the response


I have to admit I am by no means an expert. Ran the query changing variables to constants and ran with no error within PhpAdmin. Also compared the host where the script runs to the PhpAdmin settings/versions. Seem to be almost identical with the exception of the MariaDB server. Figure that since the script runs elsewhere but does not on x10, it has to be something minor or an adjustment between the two hosts that I can't seem to pinpoint. Just for the record, here is the form/script I am trying to run:
-------------------------------------
require 'require.inc.php';

if (@$adminpass) {
mysql_query("INSERT INTO $user_table (username, realname, email, password, verified, activationcode, type, points, joindate) values ('admin','Administrator', '$contact_email','$adminpass', 'y', 1, 'admin', 9999, ".time().")");

die("Admin account should have been created with username 'admin' and password '$adminpass'. Log in to test.");
}
?>
<form action=install.php method=post><input type=text name=adminpass value='password'><input type=submit value='Create admin account with this password'></form>

-----------------------------------------

 

[essellar]

It's very likely a PHP version issue. ext/mysql, the module that contains methods like mysql_connect() and mysql_query(), was deprecated back in PHP version 5.5, and has been removed altogether in PHP 7. You would need to use either mysqli or PDO, downgrade your PHP version through cPanel, or (if you're using PHP 5.5), set your error reporting to ignore deprecation warnings.

 

[surfcity]

I tried downing PHP version to 5.4. No change. Also tried another script (once again works without any modifications on another hosting platform). Thought I was getting somewhere when the main admin page came up but not only is it behaving the same (not updating the sql database with form input) but it is also completely wiping out preset values in the table if I attempt to change one of the fields in the form input. (i.e. one form has different pricing levels pre-populated with values. If I change one pricing level, then all the preset pricing levels disappear from both the pre=populated form and the sql table itself.

 

[caftpx10]

Was it checked if the script is really getting the values from the user input?

 

[Dead-i]

Hi,

After looking at the PHP code you provided, I'm not so sure your code is getting executed at all here. Your MySQL code is wrapped in this line:

if (@$adminpass) {

Are you sure the "adminpass" variable is defined? I checked your account and can't find any reference of it being set. Perhaps you meant to use $_POST['adminpass']?

As a side note, please do be careful with scripts like this. I'm judging based on the PHP code you provided alone, so I could be wrong here, but at a glance, this script looks like it could be a potentially massive security hole (since you're openly letting someone create a new admin account through a method vulnerable to SQL injection). If you haven't already, make sure you protect this page!

Thank you,

 

[surfcity]

To catpx10: I found it very difficult to paste the script into the query but did manage to type it in manually (minus the conditional statements and notification to user that it was created successfully via a return webpage). After catching a few typos I was able to get the query to populate the database.

To Dead-i: The @$adminpass is used as an if/then .. if an admin was created then the user is returned to a page that states such. I do realize the hole in the code. I usually make sure the core code works properly then add a few lines in situations such as this to seal up the potential holes.

 

[Dead-i]

Hi,

Can I ask where you are setting the $adminpass variable?

 

[surfcity]

The $adminpass is not being set anywhere that I am aware of. It is acting more as a check for the if/then condition in the code posted above. $adminpass is used in the form input to set the admin password in the sql database. If the script sees that the form was already completed, then adminpass would have a value and return a message saying that the admin had already been created. Otherwise (when it works properly) the admin is entered into the user table with form-set and preset values. Further testing reveals that anything that is passed on to the sql database results in no actual updates to the database itself. (i.e. registering as a new user does not place the info into the database nor does it return a page saying that the user had been registered. If a "garbage" id and password is input into the login fields, it comes back to the original page without a message stating "Invalid Login" as it normally should. Ironically, the same exact script is being used at another hosting site with no modifications to the code whatsoever, leading me to believe that there is something "different" with how sql is processed here , or something with a core php setting. Have this gut feeling that one minor incorrect setting is causing most of this.

 

[caftpx10]

Register globals was removed for security reasons since PHP 5.4.0.
Instead, use something like $_POST['adminpass'] as suggested previously for checking.

 

[surfcity]

That may be it. I know the globals had to be "on" elsewhere. Was going to give it a try but noticed that the code already has a "method=post" in the form coding. Doesn't that accomplish the same thing? (it's the last few lines of code listed in the original post):

<form action=install.php method=post><input type=text name=adminpass value='password'><input type=submit value='Create admin account with this password'></form>

 

[Livewire]

I'm not a PHP expert but Post vs Get I believe just changes how the variables are passed in; Post means you won't see them as part of the URL, while with Get you can do url.php?variable=value. Depending on purpose, Post may be necessary (can you imagine having a Get with someone's entire reply after the filename, or a raw username/pass?).

That was what Dead-i mentioned earlier with $_POST['adminpass']; if you're using Post for variables, you go $_POST['variable'], while using Get is $_GET['variable']. Fastest fix is to stick $adminpass = $_POST['adminpass'] near the top if it's used in several places, otherwise the "proper" fix is to replace $adminpass with $_POST['adminpass'].


If anyone who's better than me at PHP (read that as almost anyone cause I'm a total n00b) has a better explanation or knows I'm wrong feel free to correct me, I could use some learnin' too

 

[essellar]

That'll do, Mr. Wire. The only thing you've missed out on is the $_REQUEST array, which will contain both $_POST and $_GET (along with $_COOKIE). There are times when you'd want the same piece of code to be able to handle both POST and GET requests, and $_REQUEST means you don't have to write a lot of conditionals and guard clauses in order to do that. But you do still have to specify that you want to get the value from the request somehow; it's not like the old days when PHP would look at the request for any unset/undeclared value. In security terms, that not only opened a lot of doors, it also opened all of the windows and took the roof off. (It also made code maintenance a nightmare, since you'd have to look at your includes and anything they're including before you could finally decide that the value must be coming from the request.)