Cannot login to admin area

[Bosse1981]

Since a while I cannot login to the admin. I don't get any errors, not in de apache logs as well as site/assets/logs/errors.txt. I don't get a message on the admin page that the password is wrong or something like that, no message at all.

I already removed all the code from harddisk and updated it from subversion. My colleague uses the same repository and he can login. We're on the same database. Tried to reset the admin password with the forgot password function but that didn't do it.

I also cannot login from virtualbox images (windows xp & windows 7) but I can login on the webserver my colleague is running so my best guess is that it is a php or virtualhost issue. I'm running Debian Jessie (testing) with php 5.4.4 and my colleague has php 5.3.x. But I read about many succesfull installations on 5.4.

I really don't know what else to check...

[Martijn Geerts]

Type in your home template or else.

$u = $users->get('admin');

$u->of(false);

$u->pass = 'superSecretPassword';

$u->save();

Then go to a page with that template.

Then go to /processwire/ & login.

--- 

I almost forgot: Welcome Bosse1981 !

[Bosse1981]

Already tried that because I found that as a solution in a topic where was said that PHP 4.3 differs in cryptography from PHP 5.4. But if that was the problem I would've got the error "admin - Login failed" and I get no message/error at all. Nothing happens except a reload of the login page.

Edit: Forgot to mention: I also cleared all the cache, cookies etc...

[Martijn Geerts]

Does all folder in assets have the correct permissions ?

[Bosse1981]

Does all folder in assets have the correct permissions ?

Everything in site/assets/ is chmod -R 777

[Soma]

Try clearing the sessions and caches in assets folder. If theres no sessions folder, create one.

Enable debug mode in config.php.

Create new password like martijn explains.

[Bosse1981]

I am only working 1 day a week on this website, so I dived a bit deeper into this issue today.

Tried all the tips you posted, but no success. I see that no session file is written to site/assets/sessions although the folder is writable (tried even with chmod 777). When I refresh the login page or click the login-button, a session file is written to /var/lib/php5 which is the default session.save_path of my debian installation. My guess is that the session is written to /var/lib/php5 but processwire tries to read it from site/assets/sessions. I have been debugging through wire/core/Session.php, wire/core/SessionHandler.php and wire/modules/Process/ProcessLogin/ProcessLogin.module but I can't find the point where pw/php will write the session file.

Or am I looking in the wrong direction?

[ryan]

What version of ProcessWire are we talking about here? It sounds like 2.3 based on the file names mentioned, but want to double check. That seems pretty odd that PHP is writing sessions somewhere other than where specified. But ProcessWire uses PHP's native session features, so PHP is the one ultimately reading the session file rather than ProcessWire. Meaning, it's not possible for ProcessWire to read it from the wrong place, and I doubt PHP would read it from the wrong place. The only exception would be if you are using Database sessions, which is a module included with ProcessWire 2.3–did you install that by any chance? That would change the things that we need to look at. Also, just to rule out other possibilities, disable the "session fingerprinting" option in your /site/config.php and change the default session name from 'wire' to whatever PHP's default is:

$config->sessionName = session_name(); 

[Bosse1981]

Thanks Ryan, after changing the session name I can login. If I change it back, I cannot. I assume that database sessions will solve this problem, but to install that module I needed to login first .

Ok, a final comment now I have found the real issue. Using db sessions makes no difference, using 'wire' instead of session_name() still triggers the problem. After reading a comment on php.net about session_name() I checked my php.ini and session.auto_start was true. I don't know if I did that myself or it comes with a php update on debian, but setting it to false and restarting apache solved the problem of this topic.

[peterfoeng]

Hi Ryan,

I am facing the same issue again with the latest build 2.3.8 on Safari only, it seems fine on other browsers: Chrome and Firefox.

I have to put $config->sessionName = session_name(); to solve the issue on Safari. I know nothing about the underlying build is but is there any other implications by setting the session to default php session? Cheers

[peterfoeng]

Actually,

This is not the issue...there is another smart built into the login process that somehow prevent me to login straight away after logout, am I correct?

Here's what I did: login then logout then try to login again, the message popup saying: Please wait at least 60 seconds before attempting another login.

This is not happening on the older version 2.3.0.3 hmmm....* I might be going crazy lol *

[Martijn Geerts]

That is caused by Session Login Throttle.

With code below you can force Session Login Throttle to delete the entries. And make the account work again.

$u = $users->get('admin');

$u->of(false);

$u->pass = 'type-in-your-pass';

$u->save();

just throw it somewhere in you template, and call it with a browser visit.

[pwired]

Nice one. Added to my code snippets.

[Christoph]

I have a problem with login, two.

I'm building a site on localhost and from one day to another it stopped working (getting the message "login failed").

When I try to set a new password like described above, I get some notices like:

Notice: Trying to get property of non-object in /.../pw/wire/core/Pages.php

and an Fatal error:

Call to a member function numChildren() on a non-object in /.../pw/wire/core/Pages.php on line 754

helpless

[Yannick Albert]

Same here, strange login problems since some weeks. I don't want to cry, but...

 

Sometimes we have to clear the sessions folder. Sometimes we've to delete it. Sometimes we have to set magic options in the config-file. Sometimes the file permissions are wrong.

 

In my last two projects only a new blank installation made the "things" work again. That's not acceptable, for a stable release...

[LostKobrakai]

Sorry to hear that. Could you please provide some additional information (pw version, 3rd party modules, serverside software), as I'm not aware of any other recent issue report like yours. 

[Yannick Albert]

Sorry to hear that. Could you please provide some additional information (pw version, 3rd party modules, serverside software), as I'm not aware of any other recent issue report like yours. 

Thanks for your fast reply ... and sorry for the rant ;-)

Yesterday, I had to move the site of one of my "vexatious" projects (no VCS, 1-database-4-all-shizzle, conservative customer...) from stagging- to production server. The site has around 30 users (some editors, some authors, some admins).

After merging the database, no one was able to login. No errors were logged, everything seems to be chmod'ed correctly.

Server

Stagging: Apache 2.4, PHP 5.5.20, MySQL 5.6.23 (mysqli)

Production: Apache 2.2, PHP 5.5.10, MySQL 5.1.73 (mysqli)

(Uuh, mysql-5.1.x, could this be the leprechaun?)

Site

Version: 2.6.0

Strategy: delayed output

Modules: AdminTemplateColumns, CommentManager (Nothing special...)

Over the past 4 weeks, I had 2 similar problematic sites, but in this cases I got some feedback from the system and could solve the first site easily by accepting my own failure with chmod on the sessions-folder. On the 2nd site, the admin was lost in psychospace as we merged the database, creating one via API solved it.

I'll try to reproduce these shitty things later this night.

[LostKobrakai]

The mysql version should be fine. What exactly do you do when merging databases? I can imagine this creating a lot of havoc if not done with lots of care.

[Yannick Albert]

What exactly do you do when merging databases?

Whoops, don't slap me... We have moved the database, not merged.

Typically something like this:

mysqldump ... > dump.sql

mysql ... < dump.sql

However, we don't have ssh in this project, so adminer export > import did the trick..

[LostKobrakai]

No problem. With just imports/exports there shouldn't normally break anything. I do that all the time.

[Yannick Albert]

I have a problem with login, two.

I'm building a site on localhost and from one day to another it stopped working (getting the message "login failed").

 

When I try to set a new password like described above, I get some notices like:

Notice: Trying to get property of non-object in [/size]/.../pw/wire/core/Pages.php

 

and an Fatal error:

 

Call to a member function numChildren() on a non-object in [/size]/.../pw/wire/core/Pages.php on line [/size]754

 

helpless

Are you sure that the user exists you want to change?

[Yannick Albert]

No problem. With just imports/exports there shouldn't normally break anything. I do that all the time.

Damn, fckn sht... Got it!

In my case we just forgot to retain the userAuthSalt from site/config.php. Copying the hash to the productions server config file did the trick, finally.

However, no matter how easy it is to solve those problems with processwire, if you know what problem hits you, there must be more "easibility" with such problems, at least debugging messages would be a good idea.

Big thanks for your attention and effort

[LostKobrakai]

I'll doubt that, because there's no inherently wrong userAuthSalt value. You hashed password just doesn't match the database value, but the system doesn't know why it's this way.

[Soma]

You can be sure that 99.99% of your issues in near future are between your chair and your computer and not ProcessWire.

[Can]

Run into same problem recently and could "solve" it using Ryan's $config->sessionName = session_name(); trick.

Happened after duplicating a 2.7.2 PW install locally, renamed folder added host settings imported db, changed config-dev.php to new db credentials, up to this point everything works as expected.

Then I'm upgrading to 3.0.12 and get the mentioned login problem without any feedback.

Already upgraded 2 installs locally to devns without any problems.

Would love to know why wire session name is not working anymore, are there any downsides using php's default?

Uh, I'm already using db sessions for a while now

Saludos