Actually, the problem was that somehow the password was entered into the sql
database wrong. How, I don't know, but hey, at least the problem is solved.
Thanks to EVERYONE who helped with this one.. I greatly appreciate it, even
if it didn't seem like it.
Yeah, the php crypt function grabs the salt, at least that's my understanding
of it. I was just kinda lost as to why it didn't want to work correctly. Now,
that's solved, and again I GREATLY appreciate all the help.
Originally i'd thought that rom used crypt() too (system), but when the whole
thing just didn't pan out correctly, or work as it should against php's
crypt() function, I began to wonder (untill I took someone's advice and
echo'd the results, checking the dbpass against what it should have
been,etc), and lo and behold.. there was the problem!!
thanks again:)
On Monday 23 September 2002 09:22 am, Jason Gauthier wrote:
> Here is why.
>
> $pass needs to the users typed password.
>
> $dbpass is the salt.
> This is the first 2 characters of the encrypted password. this is how crypt
> knows how to encrypt it.
> Under rom it looks like this:
> if (strcmp (crypt (argument, ch->pcdata->pwd), ch->pcdata->pwd))
>
> the C library automatically grabs the first 2 characters for the salt for
> you.
> The php version of crypt may not. You might need to do that yourself.
>
>
> 9T0IB5USkXV/c salt would be "9T"
>
> So your PHP check would look more like this:
>
>
> if (crypt($pass,$salt) == $dbpass) {
> Do stuff!
> }
>
> Where $pass is the form entered password.
> $salt is the first two characters of the form entered password (You might
> be able to just pass $pass here again)
> and $dbpass is the encrypted password from the pfile.
>
> Now, I hope that helps!
