Geeklog Forums

Hi,
I've just done a fresh install of geeklog-1.4.0sr3 at www.hpcors.com/geeklog/public_html/ .
The install appears to have gone well. I used the checker script to verify all my rwx file permissions. I needed to change them from 775 to 777, then the checker script tested ok.

Then I went to the new main welcome page and tried to log in as Admin using password 'password' and it sent me to the try to log in again page. I tried to create a new user - but I couldn't and again was sent to the try to log in again page.

I've searched and read all the FAQ info about "can't log in" and searched these forums. I note others have had a similar problem but their solutions have not worked for me.

The data base appears to be created and the md5 hash of the admin password is correct (Dirk posted the hash elsewhere).

any other ideas?

much thanks for any help,
-Mark R.

When you get the "try logging in again" message that usually indicates a problem with the login credentials. So either you mistyped the username or password or they're wrong in the database or something happens to them when they're transmitted.

Try enabling the advanced logging in the session handling (system/lib-sessions.php):
The logging messages will show up in logs/error.log. See if that provides any insights ...

bye, Dirk

I have the same problem!
In error.log:
06/05/06 16:56:25 - ***Inside SESS_sessionCheck***
06/05/06 16:56:25 - session cookie not found from lib-sessions.php
06/05/06 16:56:25 - ***Leaving SESS_sessionCheck***

Sounds like either your browser isn't accepting cookies or something, e.g. a firewall, is filtering them out.

bye, Dirk

Hallo,

exactly the same problem here: same version (1.4.0sr3) updated from 1.3.9 (with mysql db update from 4.0.x to 4.1.x), nothing of the other "I can't login" tricks helped. The "try again"-screen is always displaying again and again.

I get the same error in errors.log.
Site is *********. Tried two browsers (Konqueror, Firefox) which are accepting cookies (geeklog.net works e.g.), but nothing is set in cookie management.
Im at the end of my guesses and can't get it to work...

Please, any idea might be helpful!

Hm.. I see all cookies in my Firefox browser:
Name: LastVisite
Content: 1149512185
Domain: .alex.spectr.lan
Path: /geeklog/html/

Geeklog is running on the same computer (WinXP Apache/2.0.54 (Win32) PHP/5.0.4) and i have no any firewall. In php.ini register_globals = On & register_long_arrays = On

Pls any ideas

So is Geeklog installed in http://alex.spectr.lan/geeklog/html? The way you've set it up, the cookie would only be valid for that URL.

You don't actually need to change $_CONF['cookie_path'], unless it's causing conflicts with other software.

As an experiment, you could also try "localhost" or the server's IP address as the domain name (i.e. in $_CONF['site_url']).

bye, Dirk

It still didn't work.
I noticed when I have refreshed (F5) this page http://alex.spectr.lan/geeklog/html/users.php 3 times the following message appered:"
Speed Limit
You have exceeded the number of allowed login attempts. Please try again later."

You can circumvent this message by deleting the contents of table speedlimit or setting the

in config.php to a lower value (i think).

But that's not solving the problem, just a symptom. Here is how I got this strange error solved for me:

My DB Backup was kind of messed up, the field lengths were somehow wrong (geeklog version 1.3.9 on mysql 4.0.x). Because of that, the db table couldn't hold the whole MD5 Hash for the password so that the comparison in system/lib-security.php (SEC_authenticate) was always wrong.
After changing the field length for the password hash to 32 (I did it in another way - created a new database and then just imported my old values like users, stories etc. without recreating the structure), I could solve the problem by demanding a new password - a correct md5 hash was written to database and the whole thing was running again like it should!! (that's worth the banana )

There were still some minor oddities like wrong assignment of users as owners of objects (for links, topics etc.) - this was easily solved by updating the owner_id for each object in the corresponding db table.

Now the page is fine again. The problem was not related to creating cookies etc. - the problem was that the system did not accept the password. Putting some debugging outputs in system/lib-security.php (SEC_authenticate) can light a whole tree...

Hope this helps anyone.
Me myself, I'm happy again now.

Cheers,
Schorsch