Cannot log in (was re: cookie problem)

[duuso]

hello!

I'm having similar problems. I have had SMF 2.02 about seven months and yesterday ran across this cookie error (might have been there for week or two). Forum isn't in use yet ( ;D ).
on Apache && php 5.3.3-7+squeeze14 (CGI) && mysql 5.1.61-0+squeeze1-log)

I have tried
- different browsers (Firefox, Safari)
- to register new user, it fails to same error when submitting registration form

- repair_settings.php (and renaming cookie manually)
- using .htaccess to disable mod_security
- replacing files in /sources with fresh copies

- dropping contents from sql:smf_sessions and sql:smf_log_online
- sql:smf_log_errors is empty, no multiple login errors (as suggested in some older topic)

? I cannot login and access smf settings/management panel, so where I can change allow local cookies (suggested in some older thread). It is not in sql:smf_settings or settings.php.
? I think there's no mods in use, where to check?

-- url cutted away --

edit:
- I just created fresh install with new tables, -- url cutted away -- – and for my bad luck, I get the same error. What could be the problem?


edit 2012-11
I found the error. It was in php.ini, filter.defaults = "special_chars". Chancing value back to default unsafe_raw (and rebooting php by issuing 'pkill php' in commandline / waiting for some time php to reload values; check from phpinfo() when value have changed and then login) helped.

[kat]

Can you tell us what the EXACT error is, duuso?

[duuso]

ah, sorry, I thought I was replying to this cookie error thread...

I cannot login. I provide working login credidentals, hit login and SMF shows page "index.php?action=login2;sa=check;member=N" (where N is member id).

"An Error Has Occurred!
You were unable to login. Please check your cookie settings."

SMF worked a month ago, not anymore.


edit: oh, and I'm using SMF as cms. Posts in certain boards/threads are shown in website (including attachments on few pages), but I'm using sql queries instead of SMF's SSI. Loading attachments via "http://domain.com/smf/index.php?action=dlattach;topic=NN.0;attach=N;image [nofollow]" is a bit slow, is there other way view attached pictures on site? Attachments folder is private by default, is it safe to chmod it 711 (php uses CGI)?

[kat]

I'd use 755, myself.

That's a good question, regarding the allowing of local cookies.

I'll ask the rest of the team, to see if there's another way of doing it.

[kat]

I really doubt this, because of you mentioning that the problem is with a new install, too.

But, it might just be worth a try.

In Settings.php, you can change the cookie name.

Try emptying the forum's cache, as well. (You can do that using FTP. Just delete all the files in the "cache" directory). Maybe your browser's caches, too?

I really can't see these being the problem. But, again, it's worth a shot.

Ask your host of you have full CHOWN ownership of the files on your site and that "mod_security" is disabled.

[kat]

One other thing... Can you give us a URL to your forum, so we can have a look?

[duuso]

I'd use 755, myself.

That was actually the default, .htaccess makes it private then.

In Settings.php, you can change the cookie name.

Try emptying the forum's cache, as well. (You can do that using FTP. Just delete all the files in the "cache" directory). Maybe your browser's caches, too?

Ask your host of you have full CHOWN ownership of the files on your site and that "mod_security" is disabled.

Tried changing cookie name in the first place, no help.
There's nothing in cache folder. Tried clearing browser cache before in the beginning also.
Chown -R'ed SMF directory, no help. Emailed them about mod_security.

One other thing... Can you give us a URL to your forum, so we can have a look?

--url snipped--

Emptied sql:smf_log_floodcontrol as there was few entries with similar ip to mine, no help.
Found databaseSession_enable from sql:smf_settings, no help. Default value is 1, while value was 0 sql:smf_sessions was left untouched, ie. no session made for login tries; this might be local cookie setting.

[kat]

Sure is an interesting one, this...

The Burglar! has made a suggestion, which has some merit.

Also possible problem could be that PHP is compiled as CGI module and not as an Apache module

Can you confirm, or otherwise?

[duuso]

No mod_security on the server. This problem relates only to my database table/installations as there's several other SMF's running on the same server (for example --url snipped-- ). Also as I have stated, SMF stopped working all the sudden (at least from my point of view).

[kat]

SMF stopped working all the sudden (at least from my point of view).

That makes me think "What did you do, just before this started happening?".

Installed a mod? Edited something? Maybe, even, "Did your host do something?", like upgrade the server, that kinda thing?

I'm also wondering if it might be worth you sending me a PM, with your admin login details, to see if I can log in. At least that'll prove whether there's an error with your system/browser/whatever, or the actual forum, itself.

Naturally, I'd ask you to read this, before you do that, for obvious reasons.

http://www.simplemachines.org/community/index.php?topic=87130.0

[kat]

OK. Sure enough, I get the message "You were unable to login. Please check your cookie settings.", too.

Weird.

Let's see if we can work out how to change them...

[emanuele]

phpinfo?

Just to have a look.

[duuso]

phpinfo?
Just to have a look.

You got pm.

[emanuele]

mmm...may you contact your host and ask if they changed something in the configuration "recently" (in other words just before your forum stopped to work)?

In the mean time I'll send you a PM.

[duuso]

mmm...may you contact your host and ask if they changed something in the configuration "recently" (in other words just before your forum stopped to work)?

In the mean time I'll send you a PM.

No updates have been made in several weeks, Apache was updated (during last month or so) but they didn't touch PHP. Still, other SMF 2.02 installations are running ok on the same configuration/server.

[emanuele]

Ahh...when I read:

SMF worked a month ago, not anymore.

I started thinking there was a "large scale" issue.

So you have other instances of SMF working on the same server, but these two (palsta and palsta2) are not, right?
What do these two installs have in common? Only the domain?

Would you mind give a try to the 2.1 alpha just to see if some of the few things we changed (in fact it shouldn't make any difference in your case, but since it's a 10 minutes work maybe it's worth a try) make any difference?

[duuso]

Ahh...when I read:

SMF worked a month ago, not anymore.

I started thinking there was a "large scale" issue.

So you have other instances of SMF working on the same server, but these two (palsta and palsta2) are not, right?
What do these two installs have in common? Only the domain?

Would you mind give a try to the 2.1 alpha just to see if some of the few things we changed (in fact it shouldn't make any difference in your case, but since it's a 10 minutes work maybe it's worth a try) make any difference?

I personally don't have more instances (and "palsta2" is just temporary fresh install for debugging this). It's shared machine, other users have smf up and running without problems (like --url snipped-- ). Yeah I'll try alpha.

[duuso]

Ahh...when I read:

SMF worked a month ago, not anymore.

I started thinking there was a "large scale" issue.

So you have other instances of SMF working on the same server, but these two (palsta and palsta2) are not, right?
What do these two installs have in common? Only the domain?

Would you mind give a try to the 2.1 alpha just to see if some of the few things we changed (in fact it shouldn't make any difference in your case, but since it's a 10 minutes work maybe it's worth a try) make any difference?

I personally don't have more instances (and "palsta2" is just temporary fresh install for debugging this). It's shared machine, other users have smf up and running without problems (like http://dc.kapsi.fi/smf/ [nofollow] ). Yeah I'll try alpha.

Tried 2.1 alpha, still same error.

[Herman's Mixen]

Apache was updated (during last month or so) but they didn't touch PHP. Still, other SMF 2.02 installations are running ok on the same configuration/server.

As i stated earlier

Sure is an interesting one, this...

The Burglar! has made a suggestion, which has some merit.

Also possible problem could be that PHP is compiled as CGI module and not as an Apache module

Can you confirm, or otherwise?

If they have updated the Apache configuration they have still to re-compile the php module before it is loaded succesfully

here is the diference between PHP-CGI and PHP as Apache module

An Apache module is compiled into the Apache binary, so the PHP interpreter runs in the Apache process, meaning that when Apache spawns a child, each process already contains a binary image of PHP. A CGI is executed as a single process for each request, and must make an exec() or fork() call to the PHP executable, meaning that each request will create a new process of the PHP interpreter. Apache is much more efficient in it's ability to handle requests, and managing resources, making the Apache module slightly faster than the CGI (as well as more stable under load).

CGI Mode on the other hand, is more secure because the server now manages and controls access to the binaries. PHP can now run as your own user rather than the generic Apache user. This means you can put your database passwords in a file readable only by you and your php scripts can still access it! The "Group" and "Other" permissions (refer Where can you learn more about file permissions?) can now be more restrictive. CGI mode is also claimed to be more flexible in many respects as you should now not see, with phpSuExec (refer Permissions under phpSuExec) issues with file ownership being taken over by the Apache user, therefore you should no longer have problems under FTP when trying to access or modify files that have been uploaded through a PHP interface.

If your server is configured to run PHP as an Apache module, then you will have the choice of using either php.ini or Apache .htaccess files, however, if your server runs PHP in CGI mode then you will only have the choice of using php.ini files locally to change settings, as Apache is no longer in complete control of PHP.

still i recommend that PHP must me compiled as an Apache Module instead of the CGI build

[duuso]

update 2012-11
I found the error. It was in php.ini, filter.defaults = "special_chars". Chancing value back to default unsafe_raw (and rebooting php by issuing 'pkill php' in commandline / waiting for some time php to reload values; check from phpinfo() when value have changed and then login) helped.

[emanuele]

Thanks for the update duuso!

I'm glad you solved it.