Jump to content
Larry Ullman's Book Forums

Antonio Conte

Members
  • Posts

    1084
  • Joined

  • Last visited

  • Days Won

    126

Everything posted by Antonio Conte

  1. Just a thought. You only save errors to DB if they are not previously saved, right? Why fetch ALL rows and check each one agains the current error? Why not just find a way to check if that particular error is already saved in the DB by a simple query? If no match is found, then you save it. You would of course have to use enough info in your query to make sure it's a good check, but that would be a LOT faster than checking each row. I wrote some pseudo code just so you can kind of follow my thought. $query = "SELECT * FROM errors WHERE File = '{$file}' AND Line = '{$line}' AND ErrorLevel = '($errorLevel}'; // Run query etc.... if ( mysqli_num_rows($result) > 0 ) { // Save error to DB... It's unique } // No need for an else. Error already saved... (Maybe update a DateTime field or something) Also... Watch out for SQL injection. These lines are dangerous for obvious reasons. $done = $_GET['Ref2']; //Nicer variable name $done1 = "UPDATE errors SET Viewed = '1' WHERE Ref = $done"; I don't know if this is to be had in an admin area/etc, but you should never trust input regardless. Bad thing happen.
  2. There's a big different if it's a String or an expression. You don't use squiggly brackets in an expression, but they are sometimes required with Strings. (Like when creating this SQL query String). Also note that Use your IDE to figure it how it works Personally, I would prefer to write the string like below, but that's just personal taste. $query = 'UPDATE entries SET title="'.$title.'", entry="'.$entry.'" WHERE entry_id='.$_POST['id'].';
  3. He wrote the needed functions in the last post. Just look them up in the manual.
  4. May the travel gods be on your side this time. My girlriend and I came home after two weeks on iceland yesterday. The flight usually takes around two hours, but we were unlucky. They had a staff shortage, so we spent 8 hours in the airport before leaving. Hoping to see some video from the event btw.
  5. Notepad should work. PHP is not a compiled language, so you can look at source code with any text program, but you should rather download an IDE like Eclipse or Netbeans. (Available for both Mac/Windows for free) I would think your download just simply screwed up or something. Try downloading again and see what happens. This just sounds weird. Just a tip: if you want to develop PHP, check out Xampp. It will give you a possibility to develop locally.
  6. You are missing the point, Max. Instead of enforcing strict standards, they instead offer more possibilities with HTML5. HTML5 is built to support a lot of the old elements, adding a lot of new ones, and make it easier to get browser independent code. W3C writes a guideline for how each of these elements should work, and it's then up the browsers to implement them as close to the standard as possibly. The reason for these long doctypes is because HTML is based on XML. The doctype is simply pointing to the "rules" for the parser. What this line says is only important for a machine. If you have ever seen a XML scheme, that is pretty much what that line is telling the browser to look at. This is a dictionary for how to interpret the different HTML standard.
  7. Why not use a database instead? Sound very boring to open several files or find the correct file. An alternative would be creating one file for each day instead of each error. That way, you'll have it more organized. Should be pretty easy to create. Throw in a few date/time functions to what margaux said, and you are good to go. Edit: And by the way? Doesn't errors get logged in files by default?
  8. Would like some more info. What's the use for this? What's the context. We can't really guess what you want to achieve. The reason I ask is because I'm thinking you begin in the wrong end. Please also describe your table structure.
  9. Both Google Plus, Facebook and Youtube use it. You should start using HTML5 too.
  10. Without knowing YII, I would suggest you apply a couple of print_r() and echos inside the validation methods. This way, you'll at least know that the data is passed correctly. This way, you'll also see if any logical test is not working as expected. I also think you could improve your logic a bit. An example from UserIdentity::authenticate() return ! $this->errorCode; Why not change this to something along: return isset($this->_id) ? true : false; It is just much easier to understand and read. I also suggest to make an all lower-/uppercase comparison of usernames. Improving logic also makes it easier to escape bugs. Creating some more methods would not hurt neither. An example is password checking inside UserIdentity. Something along these lines would greatly improve readability of code: public function authenticate() { $user = User::model()->findByAttributes(array('username'=>$this->username)); $dbPassword = $user->password; $inputPassword = $this->password; $dbPassLength = strlen($dbPassword); // We found a user if ( $user !== null ) { // Compare passwords if ( $this->passwordMatch($dbPassword, $inputPassword, $inputLength) ) { $this->_id = $user->id; $this->errorCode = self::ERROR_NONE; return true; } else { $this->errorCode = self::ERROR_PASSWORD_INVALID; } } else { $this->errorCode = self::ERROR_USERNAME_INVALID; } Yii::log('errorCode: '.$this->errorCode,'trace'); return false; } /** * Performs length specific comparison of two passwords. * Returns true if equal, else false * * @param {String} $dbPassword * @param {String} $inputPassword * @param {int} $inputLength * @return {boolean} True if passwords are equal, else false */ private function passwordMatch( $dbPassword, $inputPassword, $dbPassLength) { return strncmp($dbPassword, $inputPassword, $dbPassLength) === 0; } It it not my point to write bad about your code, but easier and more understandable logic gives fewer errors/bugs/weird cases. Just a generall sugestion.
  11. This seem pretty good already. You are definitely going in the right direction. Edward is correct about a new publisher table. The same can be said for "genre" in your games table. Either way. Normalization is mostly to ensure consistency. You may consider not spilling, let's say developers, into a new table even though that would be "correct". It won't really break data integrity. From that point of view, this looks very good. Improve as you see fit. Also, consider changing from MyISAM to InnoDB. The latter allows foreign keys, something that will greatly benefit you here. I don't really get your "used" table. What's it for?
  12. I'm doing something like this myself, but it's more to guard against session hijacking. This is what I do: 1. ) Concatenate the user agent with their email adress and md5 it. This is their secret key. Store as unique info as possible. I save this to a key in the session. 2. ) I compare this key for each request. I also just check if a session key is true. Here is the code I'm using. I haven't checked if it actually works as it is a work in progress, but It'll give you something to build on. The code used is pretty much based on a tutorial to guard against session hijacking, but is baked into a class. /** * session_validate() * Will check if a user has a encrypted key stored in the session array. * If it returns true, user is the same as before * If the method returns false, the session_id is regenerated * * @param {String} $email The users email adress * @return {boolean} True if valid session, else false */ public function session_validate( ) { // Encrypt information about this session $user_agent = $this->session_hash_string($_SERVER['HTTP_USER_AGENT'], $this->user_email); // Check for instance of session if ( session_exists() == false ) { // The session does not exist, create it $this->session_reset($user_agent); } // Match the hashed key in session against the new hashed string if ( $this->session_match($user_agent) ) { return true; } // The hashed string is different, reset session $this->session_reset($user_agent); return false; } /** * session_exists() * Will check if the needed session keys exists. * * @return {boolean} True if keys exists, else false */ private function session_exists() { return isset($_SESSION['USER_AGENT_KEY']) && isset($_SESSION['INIT']); } /** * session_match() * Compares the session secret with the current generated secret. * * @param {String} $user_agent The encrypted key */ private function session_match( $user_agent ) { // Validate the agent and initiated return $_SESSION['USER_AGENT_KEY'] == $user_agent && $_SESSION['INIT'] == true; } /** * session_encrypt() * Generates a unique encrypted string * * @param {String} $user_agent The http_user_agent constant * @param {String} $unique_string Something unique for the user (email, etc) */ private function session_hash_string( $user_agent, $unique_string ) { return md5($user_agent.$unique_string); } /** * session_reset() * Will regenerate the session_id (the local file) and build a new * secret for the user. * * @param {String} $user_agent */ private function session_reset( $user_agent ) { // Create new id session_regenerate_id(TRUE); $_SESSION = array(); $_SESSION['INIT'] = true; // Set hashed http user agent $_SESSION['USER_AGENT_KEY'] = $user_agent; } /** * Destroys the session */ private function session_destroy() { // Destroy session session_destroy(); } Please note $this->user_email inside the public function session_validate. I use this inside a user class, and as the user must be logged in, this variable is always available. I guess you could just change it to something other unique. If you want more security, look at the method session_hash_string(). Edit that and include more randomness and higher level of encryption if you need it. I would guess this should already work pretty good for your purposes, but you'll maybe have to do some alterations.
  13. You could possibly save some unique information like agent string, ip-adress etc. in a session. If those do not match, you unset all sessions for that computer. The more information, the better the protection. One question: how important is this? How secure is secure enough? That's pretty important to know to determine the approach.
  14. Since you have PHP 5.3, use the Filter extension instead. Defining regexes is tricky business. http://php.net/manua...rs.validate.php As an example, if you would validate an URL, this should work: if ( filter_var($url_to_check, FILTER_VALIDATE_URL) ) { echo 'The url ' . $url_to_check . ' is a valid url'; } else { echo 'Invalid url'; }
  15. What is $product_id? Is the variable set? Have you tried the query in phpmyadmin with values instead of a variable?
  16. No. Look at the result in something like phpMyAdmin. The column name will literally be what I described. That is why you use aliases. You ALWAYS use aliases if you use a function in the SELECT-part of the query. SELECT *, DATE_FORMAT(saved_date, '%D %M %Y') as saved_date FROM saved_curtains
  17. Yeah, you have to. For the sake of argument, the query won't fail, but accessing it will be brutal. (If even possible) Just imagine the code! echo $row['DATE_FORMAT(saved_date, '%D %M %Y')']; So... You kind of have to.
  18. Checked that the query actually returns what you want from it? It's often the basic that fails. Secondly. print_r()'s your friend. Your BEST friend. Use it for what it's worth. Carve this into your forehead and tattoo it on your arm: echo '<pre>' , print_r($var) , '</pre>'; Use that on the $_POST array and the db result.
  19. Login.php will have sessions because you include header.php. No worries
  20. Very. The development went better than expected. I only had to use two functions from WP and phpBB combined, one of them phpBBs hashing function. I guess the plugin will perform very stable, won't be easily affected by updates and should be hard to break. you only need to change comments.php in your theme, no edits on the WP or phpBB core. Anyone here have experience earning money on plugins? I don't know where to sell it, for how much or if I should take donations. Any advice is appreciated.
  21. For the sake of updating, I'll tell you I'm done with the plugin. I found out creating my own sessions was enough considering frequency of logins. A cookie would be the next step instead of implementing phpBB3's own session with all the pain that brings to the table.
  22. "Coffe" is a generalization here. That's kind of the point. The same would work for products. Instead of adding tables for shoes, pants, etc, you define product categories inside the products table. Now you'll be able to create type for shoes, computers, coffee, whatever. You then use product_id as a foreign key inside the products table. This way, you'll be able to write queries like... SELECT * FROM products WHERE product_id = $product_id and thus only show computers on the computer store, coffe at the coffee store, etc. This could be done by something like get: prod.php?type=5 (For the sake of this example, lets say 5 is coffee)... Hope I make sense. Generally, I would recommend you reading about table normalization. You missed a few very vital points there.
  23. Brilliant. Glad you took the time to come back to this and finish it. I'm not much of a "finisher" myself.
×
×
  • Create New...