I have a site being added to that is currently on 2.1.3 and cannot be updated for the time being.

All is running fine on localhost but when I try to login to the CP on the dev server the login page returns me to the login page? There are no errors on the page and credentials entered have been removed.

I have,

  1. Cleared all cookies on both the dev server and the local.
  2. Created a new account and imported the db to dev in case there was any corruption/clash.

4 Answers 4


Ok, this was solved by using a combination of the replies from @mediagirl and @andiefairlie, neither were quite there but they led me to the solution.

NOTE: I didn't state in the question that I am using https://github.com/focuslabllc/ee-master-config for this set up.

The issue was that the login was setting the cookies' domain to the original site (a production site that has been cloned), so .original-site.com

On local this didn't cause an issue as the site was set at local.original-site.com and the domain was correct. In contrast when it is on the dev server it is original-site.my-dev-server.com and the cookie domain is now an issue.

To resolve this I added the following to the config/config.dev.php

$env_config['cookie_domain']   = 'my-dev-server.com';

and all was well.

I am unsure if this tied to EE v2.1.3 or a weirdness in this particular install, as I do not run into this on later versions. (I am not the original dev) Your mileage may vary of course.

  • I think it's odd that the cookie config vars aren't standard on the EE config as the problem you described is a common codeigniter issue when you have cookies set for wrong domains. I've had that issue with codeigniter apps a few times! Commented Feb 20, 2013 at 10:45

Try adding this to your config.php file:

$config['cookie_domain'] = "";
$config['cookie_path'] = "";
$config['cookie_prefix'] = "";
$config['admin_session_type'] = "s";
$config['user_session_type'] = "c";
$config['require_ip_for_login'] = "n";
$config['require_ip_for_posting'] = "n"; 
$config['secure_forms'] = "n";  
  • 1
    that nearly got it for me, see comment above, the cookie_domain had to be set for each of the environments. Thanks for the push in the right direction. Commented Nov 26, 2012 at 22:17

This has happened to me before where I was accessing www. but the site was setup to http:// (note: no www.*).

Could this be the case in your scenario?

  • 1
    Yes, pay attention to the URLs it posts to - Often localhost/system will try to post to yoursite.com/system if the base_url configuration is set to the wrong site (localhost should submit to localhost and yoursite.com should submit to yoursite.com). You may need to edit this value in your database or config/config.php setting directly. I recommend using github.com/focuslabllc/ee-master-config for more friendly configurations when moving servers.
    – fideloper
    Commented Nov 26, 2012 at 22:03
  • 1
    I am using the master-config (as I have in this scenario many times on the same server etc). Their is no www v none www as it is set as a subdomain. The only issue on this is that I see the cookie domain is .thesubdomain.com rather than the actual domain? Commented Nov 26, 2012 at 22:05
  • That may well be it. Give it a shot and let us know.
    – Mutual
    Commented Nov 26, 2012 at 22:08
  • That's got it, I have added a cookie_domain to each environment's individual config and I am logging in now. Thanks @AndieFairlie Commented Nov 26, 2012 at 22:15
  • Excellent! Thanks for letting us know @AdamWiggall
    – Mutual
    Commented Nov 26, 2012 at 22:17

This sometimes happens on Chrome. One trick that works for me:

  1. Login with FireFox or Opera
  2. Go to Admin > Security & Sessions
  3. Change the cookies settings to "Cookies Only" (default is cookies & sessions)
  4. Try logging in with Chrome, but with the "Auto log-in" button checked

Your issue may be something completely different, but at least on Chrome the above trick has served me well.

  • Thanks for the answer Jae, seems my issue was a different one on this. Commented Nov 26, 2012 at 22:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.