mac_gyver

i'm wondering why you removed the $salt value from being the 4th parameter to the updateUserPassword() call? if you didn't also move the generation of that value into the updateUserPassword() function itself, your code is not going to work.

your code isn't supplying any data in the .post() method. you need to add $(this).serialize() to get all the form fields/values. untested but should work - $.post($(this).attr('action'),$(this).serialize(), function(data) {

you need to duplicate, as in copy/paste, the form code from the registration form for the password field, to use in your password reset form for the password field. the processing that is done on the password must be the same, regardless of it being for registration or password reset.

because of your use of the json output, i suspect you are using ajax to submit your form and either the data value aren't being submitted at all or you are submitting it as get data. what is the entire code for your form page?

the hash method you use during registration when the password was stored in the database table must be applied to the password during login so that you can determine if the password that was entered is the same one supplied during registration. if you are using a hash method that stores the 'salt' as part of the resulting hash value, you will actually need to retrieve the stored value from the database table and use the hash's 'check' function to determine if the entered password produces the same hash values.

are you still getting a syntax error in the httpd.conf file? if so, it's possible you copy/pasted the line(s) into that file from somewhere and they actually have something like smart/curly-quotes, which is breaking the syntax. i would retype all the quotes to make sure they are simple/straight ' or "

your form tag doesn't have a method attribute and the default when a method isn't specified is to use the get method.

you have to determine what your code is doing in the instance of it running when it doesn't work, especially since you made a correction to the code. there's no way the posted code could have updated anything with the $user_id and $salt values reversed. that would mean that you had a row in your members table with an id = a_random_salt_value. the only way that code could have worked is if your code calling the updateUserPassword() function had those two values swapped from what you have shown in the code, but then it's unlike that your checkEmailkey() function call using the $user_id would have worked.

my post above mentions three different things to check. the point of programming is to get a general purpose computer to do what you want. debugging that programming involves finding where the computer is doing what you want and where it is not. you have to check, starting at the beginning of your current process (updating a stored password/salt and then logging in using that newly updated password/salt), what the data and program execution are doing at each step along that process, until you find the point where they are not doing what you expect. since your salt/user id values were previously reversed, have you deleted the bogus row(s) from your table(s), registered a new user, and started the testing process over knowing that the registered user can log in at all, then tried to change his password? a word about the login script you found. it is just a demonstration of the concepts that someone came up with for their idea for a secure login script. it is lacking things like a verbose debugging mode/logging and complete error checking that a final/finished 3rd party login script would have. there are several conditions in the login function that could cause it to fail, but there's no indication given as to the exact reason why it failed.

have you done anything to determine what your code and data are doing? are the values being passed to that function what you expect? is the correct row in the database table being updated? when the login function is being called, at what point is the logic in it failing?

you would need to 'remember' which page you were on when you went to the login page, either using a session variable or passing that page in the link to the login page, then after successful login, redirect back to that remembered page. or you could just integrate your login form and form processing directly into any page that needs it and avoid this problem.

the order of your ? parameters in the UPDATE query and the variables being bound must match. in your updateUserPassword function, you are binding the $password variable to the first ?, the $user_id to the second ?, and the $salt to the third ? in the following - if ($stmt = $mysqli->prepare("UPDATE members SET password = ?, salt = ? WHERE id = ?")) { //$password = hash('sha512',trim($password) . $salt); $password = hash('sha512', $password . $salt); $stmt->bind_param('sis',$password, $user_id, $salt);

if you don't have a php.ini file, just create one (note what the faq says, it only affects the folder it is in, so if you have multiple levels of folders, you will need to copy the php.ini to all the folders you want it to affect.) you should only need to do this for the folder where your gem.php file is at. in a header() redirect, the & just needs to be &. in a link that is output to a web page, the & should be & (the & html encoding only has meaning in a html page.) when a link containing a & is submitted, it will be converted by the browser to a literal & and that is what will appear in the address bar.

that you could not find a php.ini file, doesn't mean you cannot use one. have you checked your web host's FAQ section? given that you have web hosting that is using the .php5 extension, it's also likely that any php.ini file is named php5.ini. check out the facts with your web host. i'm only supplying likely/common answers because i don't know who your web host is and there are multiple possibilities.

i'm going guess this person is behind a proxy server or similar that is forwarding http requests and is modifying/correcting the links. the only thing apparent is you have links that have non-url permitted characters in them that are not url encoded (your pages actually have 2000+ html validation errors, and 4000+ validation warnings, mostly due to the non-urlencoded links.) i would start by making sure your pages are all valid and error free html. i was able to trigger mysql errors to be output by altering the link, which altered the columns being selected, which means you are not checking for missing parameters before running queries and allowing the resulting error messages to be output to the visitor.

php syntax errors are only one type of error. that doesn't mean that all the php errors are being reported. unless you know for a fact that error_reporting is set to E_ALL you cannot generalize that because you have seen errors being reported that all of them are being reported. if you know for a fact you cannot use a local php.ini (did you even try) you can put the error_reporting/display_errors settings in your main file(s). short-answer: we cannot tell you the one thing to do to fix your problem because it takes some troubleshooting on your part to narrow down the possibilities. you could also have an error in a .htaccess file that is only being triggered by that one visitor. it would also help if you can reproduce the problem yourself and identify what sort of data value or what about the http request is triggering the problem. is this person having the problem a 'logged' in user, i.e. do you need to be logged in to visit the site and have access to the links that trigger the problem? is this a site you can post the url for so that someone here can try to reproduce the problem?

http 500 errors for php pages are usually due to fatal php parse or runtime errors. you should be able to set php's error_reporting/display_errors in your account's local php.ini file to send php errors to the browser to let you see what if any php errors are occurring.

what you are asking to do is simple conditional logic (if/else or switch) or even just a lookup (key/value) array to get values/content based on the user type. however, you haven't shown what exactly changes for each different type so no one has been able to show you anything. we don't know if a database query just returns different values, or if you produce different amounts of links,... in fact, you might not need to do anything in your php code and everything would just be handled in the database query statement.

the two errors mean the same thing. you are not passing a mysqli result object to the function. in your first usage of the function i gave, you are not passing the correct variable name as the first parameter to the function. you are passing $row, which is likely a row fetched from some other query and put into $GLOBALS['current_picture']. this is your statement running the query in that specific code - $comment_result = run_query($comment_query); you would call either function using - $comment_result as the first parameter because that is the variable holding the result object (we assume) that the run_query() function returns.

that refers to the parts of a query that are not data values, i.e. things like table names, column names, sort directions, ... any sort of identifiers or keywords that are being built dynamically by php code/variables. these things are not data values, cannot be bound into a prepared query, and using string escape functions won't prevent sql injection in them because they are not used in a query as string data. they must be validate to insure they contain only expected content in order to prevent sql injection.

ALL of your form processing code, the code that is using the form's $_POST data, needs to be inside a conditional statement that has checked if the form has been submitted, so that it only runs when the form has been submitted. your transaction code that stores information into the database is outside of and after your form processing conditional block and inside some 'success' message logic that gets executed after you do a redirect to that page and has nothing to do with processing the form data. it's also possible that your SELECT query that determines if the user has enough credits is failing with an error of some kind and is just letting the rest of your code on the page run. when a query fails and your code is dependent on the result from that query being valid, you must insure that the code using that result doesn't execute.

there's so much wrong with this code, both with the php usage and the OOP usage, it will take writing a book to help with it. and since books have been written that cover the basics, the OP needs to go and learn the basics of php coding, then get up to speed with php OOP, then define and start over with this code. the OOP section of the php.net documentation would be the minimum you need to study to get up to speed using or writing php OOP - http://us2.php.net/oop

your table should not have column names (nor should your code have variables) with 1,2,3,4.... in them. that's a sign you are treating the table like it is a spreadsheet and that results in more complicated code to manage the data. your table should have one row for each piece of data. that one row contains the information about the piece of data it holds. for your map/neighbour table, you would have columns for id, x-coordinate, y-coordinate, and owner_id. you should never run queries inside of loops. for this map example, you would just retrieve all the rows using one query, joining this table to any other table(s) to get the related name... information, then store the rows into a two-dimensional array using the x and y coordinates as the array indexes. then as you are iterating over the grid when displaying the page, you can check if there is an entry in the array for any x,y coordinate pair and access the information in the array for that grid position.

for the most part, you are posting to yourself. your threads haven't gotten many replies at all and nothing has been resolved because you are not making it easy for anyone to help you. the information and code you have posted isn't complete and certainly doesn't show any of the information needed to reproduce or debug the stated problems. the reason we cannot directly help you with any of the problems is because there can be many different things your code could be doing that is causing any one symptom. there is not a one to one relationship between any symptom and what is causing it. based on the symptom we cannot tell you what to fix without narrowing down the cause of the problem and it takes knowing what your code is doing to narrow down what in it is causing any symptom. even the above code is the tail end of the problem. that's your code that is producing the content on the page based on the user being logged in via a session variable. that shows nothing that would allow anyone to help you with the log out problem. the only things i can tell from the above posted code are - 1) you are trying to use php to copy/pasting together a site and are inconstant or are just not looking at or understand your code. you have short and full opening php tags. you have include, include_once, and require_once statements. you are sometimes using the () and other times not with the include, include_one, and require_once statements. you are leaving out the closing ; on some statements right before a ?> tag. you are mixing traditional logic syntax with alternate logic syntax. 2) even if the commented out error_reporting() statement was in effect, it is not showing all the php errors and you can be missing out on some error messages that would help pin down the problem. without that statement, php is not help you at all. 3) your member_1.php code should only be accessible if the current member is logged in. why have you commented out the code that would prevent direct access to it? and why then have you defined the 'INCLUDE_CHECK' constant in the member_1.php code? 4) if the member_1.php code can only be accessed by a logged in member via the $_SESSION['usr'] variable check code, why do you have a session_start() statement in the member_1.php code? the only way member_1.php can be included is if the session was already started. also, by having a session_start() statement after you have output html content (after you have output anything) to the browser, it won't work. the session_start() statement must go before any thing at all has been output on the page. some suggestions - you need to have php's error_reporting set to E_ALL and display_errors set to ON so that php will help you by reporting and displaying all the errors it detects. you should set these before most of your php code so that any problems detected in any of your php code will be reported. the preferable place to set these is in your php.ini file so that even php syntax errors will get reported and so that you don't need to remember to put them into your code for debugging and remember to remove them when the code is put onto a live server (you don't want to give hackers the information contained in the php error messages.) you should only have one session_start()/session_regenerate_id(true) statement and they must go before you output anything to the browser. i.e. they would normally be near the start of your main file or be in a file that you include near the start of your main file. you need to prevent direct access to all the included files, either by using the defined constant method or by putting the included files into a folder where direct access is not permitted. back to your logout symptom. there's three main possibilities - 1) the session variable remembering that the current user is logged in is not actually part of a session. this could be caused by a session_start() statement that is failing (there would be php error messages.) the symptom of this would be that you are setting a variable like $_SESSION['usr'], but that variable is only present on the page where it was set. anything you do on that page looks like the log in was successful, but it is not. any action you take after that page has been displayed doesn't have any session variable and it looks like the user was logged out, when in fact the user's log in was never actually remembered by the code. 2) your log in is working, but code on your page is logging the user out so that any action you take next will be met with an indication that the user has been logged out, when in fact they were previously logged out, on the previous page request, and you are only being notified of this because you caused an action to occur, another page request, that notified you that the user wasn't currently logged in. 3) your log in is working, but the url's you are using in navigation/form actions no longer match the url (path or host-name) where the session was first started and the session is not carrying over to the page that is being requested. in order to narrow down which of these three possibilities is causing the problem, it will take seeing your code.

i think for your goal of converting a multi-thousand line code file, writing a function that emulates what mysql_result() does but for the mysqli extension would result in the least amount of pain. include the following function definition into any main file that needs it - function mysqli_result($result , $offset , $field = 0){ $result->data_seek($offset); $row = $result->fetch_array(); return $row[$field]; } usage in the code in the first post in this thread (just change mysql_result(....) to mysqli_result(....)) - $num_items = mysqli_result($result, 0, 'num_items');