Thanks, Jens. Yes, I understand that straight sha256 hashes differ
from salted ones, and that cake salts by prepending the core salt to
the password. I had mentioned above that I included 'hashPasswords()'
function in the model, which has been 'automagically' replacing the
hash with the proprietary 'salt' logic and a sha256 hash. So that
part is fine. I've debugged the $_SESSION variable there and verified
the success of the hash.
I had almost given up and switched to 'Authsome,' because my
frustration levels were high. I happened to restore my source code to
an earlier state, after which I ran the page to document the $_SESSION
array, AND THE LOGIN WORKED AND REDIRECTED!!! There may be a couple
of issues affecting this behavior, however I believe one part of the
solution requires use of [autoRedirect = true] as a component
setting. For me, I'm finding that this value HAS TO BE EXPLICITLY SET
even though it defaults to true. For me, setting it to true when the
component is initially configured made a difference.
I'm also suspecting my difficulties identifying the problem arose as a
result of [1] a non-standard implementation (using hashPasswords()
function in the model as set forth by { $this->Auth->authenticate
statement) = ClassRegistry::init('User') } and [2] the
misinterpretation of what was actually happening as a result. I
believe that what may have looked like a failure to redirect may have
actually been a successful redirect but to the wrong location (meaning
a redirect back to '/users/login' !!!). This redirect would be
internally stored as part of the auth component. I've noticed that
changes to the auth component are not reflected unless I clear the
browser history. If the redirect wasn't working (before autoRedirect
= true), this might explain what looked to be failed login attempts in
addition to masking effects of beneficial changes to the auth
component configuration.
The essence is this: A workable configuration (requiring explicit
"autoRedirect = true") appeared to fail, but because I had spent the
latter part of a day setting up 'Authsome,' I was able to discover
that it was indeed workable once the session had expired. This also
revealed the importance of clearing browser caches when configuring
this component.
On Jul 12, 6:40 am, Jens Dittrich <[email protected]> wrote:
> You inherited a table with usernames and passwords where the passwords where
> hashed with sha256 right? Was that a custom sha256 implementation? Was it
> salted? CakePHP salts the passwords when hashing so the salt value is very
> important for the output. sha256 hashed passwords are not the same as salted
> sha256 passwords, the hash value differs.
--
Our newest site for the community: CakePHP Video Tutorials
http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others
with their CakePHP related questions.
To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/cake-php
