objnoob

Good point! Yes, you're exactly right! Since it includes user input, it would be very wise to pass it through htmlspecialchars before outputting it to the browser. You should be validating too... Check if 120 is a number, if not a number tell user there is an error! If number then construct SQL and execute.

You're mixing procedural code with object oriented code! You're also mixing mysql_* with mysqli_* Try to connect with this! $conn = new mysqli($hostname, $username, $password, $dbname); // check if connection attempt returned an error number if(mysqli_connect_errno()){ echo 'Error connecting to database!'; exit; # kill script; couldn't connect to database } Delete this because we're are not using msyql_* we're using mysqli, which is what you want to use! mysql_select_db($dbname);

you use htmlspecialchars when echoing all user input to the browser. this ensures none of the user input is treated as HTML and prevents XSS ( cross-site scripting ) you use mysqli_real_escape_string() on all user input when you're using it as part of an SQL statment. this ensures none of the user input is treated as SQL and prevents SQL injection! You do not have to call either for mysqli_error() since it is not user input! No, mysqli_real_escape_string() does not convert HTML reserved characters to their entities.

An alternative to using FetchAll() is Fetch(). You can build your own $rows array with customized indices... $rows = array(); while($row = $stmt->fetch_assoc()){ $id = $row['id']; # store id column in variable if we're going to be unsetting it unset($row['id']); # unset id if you don't want it to be part of the array, we can do this since we'll have the indices set to the ID $rows[$id] = $row; # add row array to the rows array }

You could break out of the loop after finding it, foreach($rows as $index => $row) { if($row['id'] == $id){ $page = $index+1; break; # we found what we were searching for, break out of loop } }

You should use your web browsers web developer tools to view the cookies set by your site. You can check if the session cookie is being set, and whether or not the value of the session cookie is changing between requests. You can also check the request headers, using these same developer tools, to determine if the cookie is being passed to the site on subsequent requests.

I would have taken a different approach! Instead of modifying if(!is_numeric($value)) $value = "'" . mysql_real_escape_string($value) . "'"; I'd modify $sql="INSERT INTO spikes (type, brand, gender, size, hand, new, price, description, imgname, date, name, userid, phone) VALUES($type, $brand, $gender, $size, $hand, $isNew, $price, $desc, $imgname, $date, $name, $userid, $phone)";

Yes, session id regeneration is a defense against session hijacking. Leaving a session open for a year defeats the purpose of session id regeneration as a form of protection! When the user stops making requests... the session id does not regenerate! I'm not here to write any code to your specification. The authenticating 'Remember Me' key is salting, not once but twice, and hashing an already salted and hashed password. The user password should already salted and stored as a hashed value in the database. You never store naked user passwords in case your database becomes compromised!

It's not even a salt. Strings are salted before being hashed to prevent them from being found in rainbow tables. In my authenticating 'Remember Me' example, you'll see that I've salted the user's password twice before hashing it with sha256. Once with the user's internal unique database id, and once with a hard coded string 'Im_A_SaLTiNE_CrAcKEr'

Nope. Nope. Nope. session.gc_maxlifetime is a misnomer! And it should be renamed gc_minlifetime! because it's the minimum time the session is to remain open on the server, unless explicitly deleted. In reality, the actual session alive time is a probability that the garbage collector run! You can make the probability 100% that each request will fire the garbage collector. Even doing so... the session is theoretically alive until the GC cleans it up... session maxlifetime = 400 lifetime = 500 the session is alive until the garbage collector fires to delete the session.

Nope, not a nonce. How do you consider this a nonce when it is used over and over to remember and thus re-authenticate the user? If you're creating custom strings (to be used as hash) that are not directly derived from the user detail already on file, you better invalidate these when the user changes their password. Or you'll need a forget me button! And, yes.. I agree a 'Remember Me' is insecure to begin with! I've never in my entire career implemented a remember me that was authenticating!

I cannot lend you any more support. You've missed the numerous points I've made, and the least I can say is you should seriously reconsider your approach to sessions! I don't code games, I code life! :]

Sure it can, but it's better to exposed hashed private details than it is to expose a year long session cookie that grants full access to your user's account! And, like I said..... a number of times. If the remember me hash is derived from the user's password, when that user changes their password... any old keys derived from the old passcode wont validate. In otherwords, when I change my password, all the computers I've used to sign into your site and clicked remember me have now forgotten me!!!

One thing you can do.... which I don't recommend, but is a better solution... Have 2 types of session cookies! You can designate the type in the session name... SESSION_USER, SESSION_VISITOR Naming your sessions with Session, or using the default session name is a bad idea. You're basically telling everyone which cookie is the one they want to steal! First thing to do is check if one is set. You can do this using $_COOKIE superglobal EX: isset($_COOKIE['session_user']) If the cookie is set, then you know the expiration date, because when it's a session_user it expires a year from now, if not... it expires at browser windows closed. I want to mention the session cookie expiration time has nothing to do with the set maxlife of the session on the server! It's rare that I ever start a session for a user that has not been authenticated. In other words, I don't create sessions for visiting users.

You can check if a session cookie exists using the $_COOKIE super global before doing any sesssion_* calls. because... it's a remember me cookie! and it still authenticates the user with username and password before starting a session.​if user changes username or password, all previous remember me keys will not authenticate because... you're not keeping the session open for eons. keeping the session open with extended session inactivity invites session hijacking. because... if the user deletes their cookies after you create this year long session, they may eventually log back in and now you have 2 year long sessions open on your server for the same user. delete cookies, long back in and now you have 3, year long, sessions open on your server for the same user. delete cookies, long back in and now you have 4, year long, sessions open on your server for the same user. delete cookies, long back in and now you have 5, year long, sessions open on your server for the same user. ALL THESE SESSION ARE VULNERABLE TO SESSION HIJACKING!!! Thanks for the link, however you will benefit from reading that more than me!

Anyways, you should try $a = (array) $array[$key]; $a['stared'] = 1; $array[$key] = (object) $a;

What is your error?

Consider having a single categories table. In this table you would have a primary key that is auto incrementing. You would have at least one other column to store the id of the parent category. If the category doesn't have a parent category you just set the parent_cat_id column to null. Then you could do a self left join. SELECT cat_id, cat.cat_name, parent_cat_id, parent.cat_name FROM categories cat LEFT JOIN categories parent ON cat.parent_cat_id = parent.cat_id; This will select all of the categories detailing the category id, the category name, the parent category id and parent category name (if there is a parent) If you want to select all of the categories that are a child of category with ID 1, then you can WHERE parent.cat_id = 1 SELECT cat_id, cat.cat_name, parent_cat_id, parent.cat_name FROM categories cat LEFT JOIN categories parent ON cat.parent_cat_id = parent.cat_id WHERE parent.cat_id = 1;

Something about what you're saying doesn't add up... The categories 57, 58, 59, and 60 are all categories included in the result set thanks to WHERE category IN (57,58,59, 60) I don't understand when or where category 58 becomes a child of 57.

Well, if you're sorting by date... ORDER BY o.date DESC there's a chance of having duplicate categories sections. Like, I said you should sort by category table primary key column ( and then by date if you want ? ) $result = dbquery("SELECT o.*, c.id catid, c.name catname FROM ".NODE." o LEFT JOIN ".ARGUMENT." c ON c.id=o.category WHERE category='57,58,59,60' ORDER BY category, o.date DESC");

Yes, the quickest way is to sort by category and check in the loop when you hit a new category. $cat = null; # no category processed yet while ($row = dbarray($result)) { if($cat===null || $cat <> $row['catname']){ // first category, or the category has changed echo "<tr><th>{$row['catname']}</th></tr>"; # print category name $cat = $row['catname']; # set $cat to the new category } echo "<tr><td class='tbl'>".$row['name']."</td></tr>"; # print the item $i++; }

And, not to forget... it doesn't guarantee the server will even keep the session open for a year. I try to help you and you ridicule me. Why don't you go... ?logout=true Lol, just kidding. Seriously, You don't even need =true since logout will never be anything else and an empty string is considered set and (isset($_GET['logout'])) will be true just using mysite.com?logout

Why would you even need to get the expiration time when you're the one setting the expiration time? When the user logs in, if they checked stay logged in the set cookie expiration in a year, otherwise set expiration time to 0. when they click sign out delete the cookie. You need do nothing more, but this is NOT recommended! Anyways server could care less when your stupid cookie expires. Cookies are a browser thing. If you need the cookie expiration.... then STORE IT!

Are you smoking crack? 1. i chose $_GET because you're using $_GET already 2. the key is derived from the user's password or password hash. if the user changes password, any old auto login keys will fail authentication. 3. adding something random makes no sense. you can't authenticate randoms! 4. keeping a session open on your server indefinitely is pretty stupid. hello session hijacking! Anyways, I'm not here to write the code to your exact specifications. I'm here to show an example of how it could be done with no warranties implied!

It's called dependency injection! Google dependency injection and learn all about it!