Jump to content

mac_gyver

Staff Alumni
  • Posts

    5,382
  • Joined

  • Days Won

    173

Community Answers

  1. mac_gyver's post in using LAG was marked as the answer   
    based on the error message, you are using mysql. the lag and over functions don't exist in mysql. they are ms sql features.
  2. mac_gyver's post in php page working in google chrome but not on firefox in ubuntu was marked as the answer   
    re: post #6. there's nothing obvious in the code that would account for the problem/browser difference. if i have time i will investigate the code further.
     
    re: post #7. isset() tests if the variable is set or not. the boolean true from the print_r just means that it is set. when it is set, it can have either a false value or it will contain the fetched row from the query, so, adding an isset() around it is meaningless.
     
    any chance that in the browser where this works, the browser has been configured to remember passwords and it's actually the browser that's supplying the password and in the browsers where this doesn't work, you are actually typing the password and you are using the wrong one, either because the one that works was originally entered/registered with some fumble-finger accidental extra/wrong characters in it, or you are typing wrong password where it doesn't work?
     
    in any case, you need to determine why the query is not matching any rows. here are two things to do -
     
    1) temporarily modify the sql query statement so that it only tries to match the username. if the code then results in a var_dump of the $user variable with the expected row from your database table, that means that the username comparison is working and it's the password that's the problem.
     
    2) echo the md5() hashed password value and see if it is the same as what is stored in the row in the database table. i suspect it is not. i would do this for both the browser where it works and at least one where it doesn't. the echoed hashed value should be the same for all browsers and it should match exactly what is stored in the database table row that corresponds to the username you are testing with.
     
    edit: actually, step #1 in the above may not be so temporary. if you switch to using password_hash()/password_verify(), you will need to match the username in the query, retrieve the hashed password and pass the entered password and the retrieved hash through the password_verify() function to see if they match.
×
×
  • 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.