Ok... well... all was going well with Apache2 and PHP5 on the new dev environment, so I upgraded the production server... and the same problem is still occurring! I am so confused! I didn't do anything custom with the Apache2 or PHP5 configs on production; I used the recommended settings. :(
The grep -i showed some Session->valid and Session->read calls but the only Session->write or Session->delete calls were in d_auth.php. What's more is that I'm using this Users/login action as the default / route for this project so this issue is occurring without the user having to navigate to any other pages/actions at all... :-/ I'm off to search trac.cakephp.org now but this is crazy. The only difference between dev and prod now is dev has mysql5 and prod is still mysql4 (I am using cake_sessions in the database - I'll try switching back to files, see if it helps). Thanks again Diether, -volve On Jan 20, 5:34 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Well, something is removing items from ( or maybe totally wiping ) > your session, and i don't think it's dAuth ;-) > did grep -i session on your project yield anything? > But at least you have an environment where it works. try comparing > php.ini's, apache.conf's , looking up bugs for cake and php ( session > bugs will probably be also in this group), downgrading the php of the > new environment etc ... > > good luck! > Dieter > > On Jan 19, 5:33 pm,volve<[EMAIL PROTECTED]> wrote: > > > Thank you very much for getting back to me Dieter! > > > The salt is definitely "in there" before attemptLogin is called as I > > can stick a print_r in Users/login action and I see the salt at the > > top of the page when I load the login form. (But the print_r inside > > attemptLogin shows it as missing when submitting the login form.) > > > I spent some time last night setting-up a second development > > environment with PHP5 and... the problem hasn't reappeared... I know > > this doesn't really make sense, but I wanted to share anyway. Maybe > > there's some quirky CakePHP Session handling bug that isn't present in > > PHP5 ? All I did was copy over my previous app directory into this new > > environment and changed database logins. > > > I'm still baffled, but at least it's progress (I think). :) > > > Thanks again, > > -volve > > > On Jan 19, 6:38 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > > > I basically did a > > > > fresh install of the v0.3 files from bakery.cakephp.org and wanted to > > > > get them all working as-is before customizing (to make sure there was > > > > nothing in my project interfering, I grep'd the entire source tree for > > > > references to 'salt' and only found the new dAuth ones). > > > > Well, this is weird indeed. I also used the powers of grep on the > > > dauth sources and found out that at only 1 place the salt is written > > > into the session, which is in the function newSalt() of the component. > > > By grepping on Session i could not find a place where the salt might > > > be removed or the session cleared or anything like that. I suggest > > > you also grep on Session in your entire project to find out if > > > something else might be interfering. ( use grep -i to be sure you > > > dont miss anything) > > > > Also make sure that the salt is put in the session before trying to > > > read it out ( eg you're not going directly to the attemptLogin logic > > > before opening the login page. and make sure you have a salt there > > > first) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
