[RESOLVED] Login Problem
Media Wiki: 1.16.0 PHP: 5.2.12 MySQL: 5.0.67-log
Hey, I installed the wiki on a local server and configured all settings, but when i wanted to log in with my admin account, i got this error message: "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again" I tried it again and again, but the result was equal, the same problem when I try to register a new account.
I get the same error as thread starter..anyone pls can help us? Im using 1.16 + wamp.
I'm having the same problem on the new clean installation when trying login or create a new account - any solution for it?..
Probably something is wrong with your sessions; most likely PHP is not able to write to your sessions directory. Check your php.ini for the sessions directory and if PHP can write to those files.
I got the same problem since soon, but not for all the installations on the same server (same version). Apparently the cookies are not good. It seems to come from the repertory of installation...
The connection to the database seems also be examined in this problem !
Looks like this has to do with setting a DNS CNAME.. it's only happening in IE8 for me... anyone have a fix?
Only happening in IE8 makes it sound as if you disabled cookies in that browser. Check to make sure cookies are enabled.
Why do you think this has something to do with a DNS CNAME?
The same thing just started to happening to me, after i renewed my hosting and domain
I had this problem when i was trying to access a mediawiki's instance installed on a Virtual Machine with XAMPP 1.7.2 with the nameserver. eg.: http://name_of_the_server/mediawiki but when i try to access by this way: http://10.12.206.57/mediawiki, i can access.
I think that this error is related with the DNS.
I have the exact same issue now, fresh install. Anyone going to help with this??
I found this solution:
go in your LocalSettings.php and at the end add the following code of line :
Create a folder "tmp" in your wiki installation directory. give rights 777 (permissions)
Which worked for me.... also, check to make sure your disk has space
This worked perfectly for me on a new install. Thanks, you're the first person to actually give a usable answer to those that don't have access to the server's PHP.ini files that I could find.
Eh?! Don't put it in web-accessible directories, or your user accounts will be easily hackable.
This worked for me. I had this problem with MW 1.18.1 after I upgraded my hosting with godaddy and they changed my ip and dedicated ip. Mediawiki kept asking for cookies to be enabled (they were enabled) on all types of browsers and platforms including the iphone. Problem solved for now, even though I'd like to know if it will come back after an upgrade.
Same problem, can't even register or login as admin. Enough space is present.
Looks like it was caused by using $wgMainCacheType two times in LocalSettings.php, now it's solved.
Hi also have the same problem where the IP address work perfectly yet the hostname fails.
Would love some kind of explanation?
The problem i'm experiencing just seems to be Internet Explorer only. Firefox and chrome are un-affected either by the hostname or IP address.
If I goto the login page a 'sess_xxxx' in the /tmp folder is created. If I attempt to login, or just refresh the login page this seems to set brand new a sess_xxxx everytime.
I have checked the apache logs and the client IP address is always the same regardless if i used the hostname of IP address.
Its not a permission issue.
I have also tried the following which was suggested with no success. $wgUseSquid = true;
Some suggestion would be greatly appreciated.
[SOLVED: My issue was caused by having an 'underscore' in the hostname example http://my_server - IE looks though it doesn't handle the underscore in the hostname as well as FF or Chrome does. Hope this helps anyone else using Mediawiki within their local intranet]
had this error and the problem is that the facility lacked a standard memcached adding correct configuration
$wgSessionsInMemcached = true; # optional
... a little more resolved. This can also be a symptom of being short on disk space.