Jump to content

Jessica

Staff Alumni
  • Posts

    8,968
  • Joined

  • Last visited

  • Days Won

    41

Everything posted by Jessica

  1. Thanks I got divorced, got remarried, and now have a 20 week old son. So...I've been a *little* busy. Had some downtime this week and felt like visiting :-P
  2. <?php $total = 0; foreach{$array1 AS $k=>$v){ $total += $v*$array2[$k]; } echo $total; ?>
  3. 1. Post your code in code tags to fix the formatting issue, and make it easy to read. 2. you'll want to do a foreach, with a value defined before the loop to hold the sum. Do you need the individual multiplication results or just the end total?
  4. I could swear this said "Rat Sleeping Bags". I was curious how you convince the rats to sleep in them. http://lmgtfy.com/?q=HTML
  5. I believe you could do this with an outer join, and a case statement. I've been working on a project in MSSQL for 2 years so I had to look up MySQL's syntax for it but I think this is correct, didn't try it. SELECT t1.x, CASE t1.y WHEN NULL THEN 0 ELSE t1.y END CASE, CASE t2.z WHEN NULL THEN 0 ELSE t2.z END CASE FROM t1 OUTER JOIN t2 ON t1.x = t2.x
  6. If you had it enabled and set to the right settings, you wouldn't have seen a blank screen the first time...
  7. What happens if in your browser, you go directly to the css file? Do you see the old or new? I've noticed a big problem with caching of CSS files and sometimes going and viewing the file directly clears it. I assume you're doing a clearly obvious edit like changing a color, right? And it's not being over written by any other styles?
  8. Start trying it and if you get stuck, post code.
  9. If you store it in sessions, the user would only need to close their browser and open it up again to "cheat". You will probably need to store some info like their IP address, in your database.
  10. Yeah, I'm the one here who's incapable of admitting when I'm wrong. *eyeroll* People say that *I* am rude. But rather than actually having a discussion, you'd rather be sarcastic and pretend like it's shocking that someone might not just take your word as gospel when you say "don't do X". When people question *MY* comments I can almost always back them up with an example either in actual code or in documents and articles. Rather than saying stupid shit like "hashing brings kittens back to life" you could actually, you know, answer the question and teach someone something. I fully admitted here that I am not an expert and I guess you decided that was liberty to treat me like an imbecile. @The Little Guy - thank you for coming up with an actual example, I appreciate you actually taking my question seriously.
  11. I understand that there is no need to, but you guys are now insisting that by doing so, you are compromising security, and have yet to explain how. Simply saying SQL injection isn't an explanation. You have YET to explain HOW by the php script selecting the hashed password, ANYONE could then get it and look it up in a rainbow table, or do anything else with it. That's my question.
  12. database access! What do I win? What are you TALKING about? How on earth is selecting a hashed password different from selecting a username, or id, or last_time_logged_in, and how would any of that give anyone else access to your database? We're talking about a site user's login password, not a database user's password.
  13. 1. I never said do a select * 2. What SQL injection? If your site is open to SQL injection, it doesn't matter what you SELECT, the person doing the injection can select whatever they want. Are you trying to imply that you never do ANY Select statements? (not SELECT *, I get that you think that's the devil's work, but selecting anything) For that matter, if you're open to SQL injection, it doesn't matter if you're selecting, updating, whatever. Since you're so concerned with security, your site should definitely be protected from SQL injection, not relying on security by obscurity. What I gain by selecting the username and password at the same time is the ability to do what I described in my original complaint about this, without doing a second select statement. That is all. I'm not saying anyone has to do it this way, I just don't see what the harm is.
  14. select (select count(*) from users where username = 'dog' and password = md5('xxxxxx')) as user_found, (select count(*) from users where username = 'dog') as use_exists; You realize that's still two queries? Which is fine, it's really not that big a deal. I was mostly being hypothetical on not doing 2 queries.
  15. if you return the encrypted version of the password from the database, what's the point in encrypting it in the first place? ... Did I miss something where one way hashes no longer exist??? Look I am all for security but in this example, if you look at the scenario I described above, it's not user friendly to NOT differentiate between a password mismatch and a username not being found. You can't argue that it's user friendly to not tell a user they mistyped their username. If you're concerned about brute force attacks, limit login attempts!!! BTW, I'm pretty sure I DID say seriously. I'm not claiming to be an expert on security. I'm seriously asking, if IN a login script, there is an actual security concern with selecting an encrypted version of a password (like 35d05678b659f08cb7e40ec5fb6f1b38). In your PHP script. The same place you store mysql username and password NOT encrypted. The first person who can tell me what string I typed to get the above hash, I'll personally mail you a $20. I'm dead serious. I'm posting it here on a public forum (no, that's not my real password), and I'm talking about selecting a password from your database into a php script.
  16. Did you read my above example?' Yes, I accidentally typed password where I meant username. If you look at my example of WHY it's annoying to not let them know if the username is invalid. Brute force shouldn't even be an issue, and depending on the nature of your site, usernames are already visible.
  17. That doesn't make sense. You have to specifically look for the break. If you only indent the code in the case but not the break, you know that as soon as the indentation stops there is a break. No you don't, it could be the next case. You are looking for two non-indented lines. It's kind of silly to tell someone they don't know what's easier for their own self to read. Studies show all-caps is hardest to read but some people insist it's easier for them to read, are you going to say they are wrong and don't know their own comfort?
  18. Again, what does it matter if it's encryped? I'm asking seriously. Who is going to be able to see it, and even if they did what can they do with it? You would return an email address in a query, right? That's much more useful IMO than a encrypted password. I don't think security and usability are inversely related, I'm talking about this one instance where someone has said it's a security risk to let a user know if they have entered an invalid password and you should NEVER do it. That's ridiculous. The query you provided answers my other question, thanks.
  19. I just meant reboot Firefox to disable addons. Hope you figure it out!
  20. I'm on Firefox 11 but it's on Windows. do you have any add ons? I'd disable them all and reboot. Here's what I saw.
  21. To send your original values from the form, you can use sessions, or you could put them in the url of the pagination link and use $_GET.
  22. HOLY BUZZWORDS. I viewed it in Firefox which is what I assume you are talking about, and it looked fine.
  23. Many people have multiple email address. I agree, but the idea of not telling a user if they have accidentally entered an invalid username in the name of security just seems like it would only lead to frustration and not actual security. Agree on the passwords, I'm saying that's a reason to NOT be purposefully obtuse towards users. Users are not perfect, they are usually pretty far from it. You assume they are idiots and handle as such.
  24. Well don't use the example query, for one that's not even a valid query, and it's clearly not yours.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.