I transferred my magento installation on ubuntu with files and mysql db dump to my development machine on Windows 10 with XAMPP installed.
I can up the frontend, but I cannot login my admin backend.
I am sure the password and user name are exactly as my installation on ubuntu, why happened? It just stay on the login form and saying all the time invalid formkey, I viewed the source formkey value just generated there.
There mentioned issue with charset, tried no help.
There is no any error logged in var/report and XAMPP apache errorlog, access_log to /index.php/admin is 200, looks good.
will you have any idea? thanks in advance.
Possible causes include
Incorrect permissions on var/session, preventing session files from
being saved
Incorrect configuration of database/redis/other session storage,
preventing saving of session values
A module is instantiating sessions to early, preventing the correct
session names from being set
The cookie domain in System -> Configuration -> Web -> Session Cookie
Management doesn't match the actual site domain.
You're using the localhost as your server domain, and using a version
of webkit that has trouble/bugs setting cookies for localhost in some
situations.
Easier is just to use the IP-address 127.0.0.1 to access Magento.
Open magento database and run below query.
update `core_config_data` set `value`='/' where `path`='web/cookie/cookie_path';
update `core_config_data` set `value`='[magentohost]' where `path`='web/cookie/cookie_domain';
If you have setup multiple store with subdomains, add Cookie Domain: .magentohost.com
Add a dot “.” follwed by Magento URL.
source : CodePetals
Related
joomla backend administrator login panel not working. if entered with correct username and password it just loops(it just refresh).
enter image description here
It can be due to mainly two factors i.e sessions and plugins
if you try to increase the session time in your global configuration settings to a much higher value like 99999999 you will face this issue. The solution will be to edit your configuration file to change to a reasonable value like 1500 or 3600 etc for a localhost server.
public $lifetime = '1500';
if none of your authentication plugins are enabled you will still face the same issue. So you have to login to phpmyadmin. Go to your Joomla database and find #__extensions. There you search for authentication plugin plg_authentication_joomla. Enable the Joomla authentication plugin i.e change enabled from 0 to 1.
There are many causes for this problem, such as:
A hacked website
Wrong tmp/log paths in the configuration.php file
A disabled authentication user/plugin
The URL "http://localhost/magento/" is not accessible.
Unable to read response, or response is empty
When install new magento in localhost.
As Ankit Parmar said, you can check
Skip Base URL Validation Before
...but you might encounter problems later on. This message appears probably because your domain is not public or not reachable. If you skip Base Url Validation, you will be able to finish the installation but you might get the strange problem of being able to log in but not to access the admin section (get redirected to the login page without any error message even if you see you're logged in by looking at the URL).
Rather than installing Magento under localhost, you should add a fake domain name in your host file and set up a vhost accordingly. you may then re-install Magento by accessing the fake domain name in your browser. You may setup the domain name in the core_config_data table if not done.
More over here: https://magento.stackexchange.com/questions/39752/how-do-i-fix-my-base-urls-so-i-can-access-my-magento-site
My Magento web site home page has a redirect loop error. When I try to open it it goes to my old server url and gives the error:
The webpage resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.
When I try to go into admin it takes to me old server admin url without any error.
I down loaded the fresh data base and connected my store to that it works fine but when i connect it my old data base it give same error.
Please advise me.
This isn't an ideal solution, but I was having issues with Magento 1.9.x.
The setup was: Nginx Proxy & SSL Terminator => Apache Webserver
No matter what I did enabling SSL caused a redirection loop. I narrowed the issue down to Magento rather than the Nginx configurations.
It was like Magento didn't know it was receiving a secure connection from Nginx even though the correct headers were set.
The dirty solution was to add some code to the very bottom of index.php within the magento root directory (ie. /var/www/magento) just before the Mage::run... line, like so:
if( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) ) {
$_SERVER['HTTPS'] = 'on';
$_SERVER['SERVER_PORT'] = 443;
}
Mage::run($mageRunCode, $mageRunType);
Wrong permissions can also cause this to happen. So in addition to truncating the var/cache and var/session folders, go ahead and make sure that you have the proper permissions on the app, skin, and includes directories, sub-directories and files. I believe the suggested permission setting is 644. You can do this with a proper FTP client such as FireZilla.
Go to table core_config_data
Update these value to be your localhost url(or whatever url you are providing while installation):
web/secure/base_url //(new url)
web/unsecure/base_url // (new url)
Empty the var folder.
I got it fixed.
I manually deleted my cache i was unable to login in my amdin and it get fixed
My issue was Cloudflare, put it in Development mode and it worked. It was cache related.
Issue: ERR_TOO_MANY_REDIRECTS - redirected you too many times
This issue is related cookie domain name.
For ex: if you already installed Magento 2 in www.example.com, and now you change magento base path to sub domain path like www.subdomain.example.com means, then you need to update your cookie domain entry inside of core_config_data table. You cannot access magento 2 backend so you can use following query to check record exist else use insert query.
SELECT * FROM `core_config_data` WHERE `path` REGEXP 'cookie_domain'
if record exit then update subdomain.example.com to the value column.
else
INSERT INTO `core_config_data` (`scope`, `scope_id`, `path`, `value`) VALUES ('default', 0, 'web/cookie/cookie_domain', 'subdomain.example.com');
Then flush cache using command php bin/magento cache:flush
Refresh magento 2 admin, now you can access admin. try this. thanks.
Note: if you are not using cookie domain, then don't configure this settings, if you configuration wrong then also you can face this error, so to fix that error update value to default configuration.
I had the same issue and after reloading and reloading my page I noticed that the error message responded to www.mydomain.tld and sometimes to mydomain.tld. I'm using Plesk on the server and I remembered that I set the Domain to always be called without www. I just changed that to none in the hosting settings of the domain. Lucky me, that solved that issue. Hope that helps someone else.
I have magento installed in a subdirectory. www.domain.com/subdir/magento
This site worked perfectly at one point. I changed nothing, until my client said he couldn't login to magento admin.
I logged in just fine from my computer, but on his computer it just redirected back to the magento admin login without an error message and a url that looked goofy like this:
http://domain.com/subdir/magento/index.php/admin/index/index/key/3097210b826ac4a86d7531cb4089c9d0/
I thought that his cookies were being blocked, but that was not the case.
My magento settings were secure/unsecure baseurl: http://domain.com/subdir/magento/
web cookie path: (blank)
web cookie domain: (blank)
After clearing out var/cache, I found that I myself could not login to the admin either, with the same exact issue.
I tried the following settings without luck:
path: /
domain: domain.com
path: /subdir/magento
domain: vigrond.com
I also tried commenting out those lines in Varien.php, but that had no effect either.
My server account is a VPS and it has plenty of free space.
So I'm pretty much lost, wondering why this happened in the first place when it worked before (didn't change anything), and why it's so complicated?
Any help appreciated
If a login error message ("invalid password", etc.) isn't being displayed it's almost always a session cookie problem. In order to rule it our entirely, use Use your browser's cookie viewer and/or your favorite HTTP traffic sniffer and check
That all the cookies have proper expiration dates after being set
That the session cookie has a consistent token name/value for each request
That PHP, when running through Magento, has the various session lifetime ini settings at a reasonable value
That PHP can write to whatever it's using as a cookie storage medium
That the server's time matches the real time, and that PHP itself has a timezone set
Find app/code/core/Mage/Core/Model/Session/Abstract/Varien.php. in your Magento install folder. Comment out the lines (see below) 80 to 83. The line number may vary.
// set session cookie params
session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath()//,
//dependes which versin of mage you are using, you may comment these as well
//$this->getCookie()->getDomain(),
//$this->getCookie()->isSecure(),
//$this->getCookie()->getHttponly()
);
This is caching issue. Which recently Magento community confirmed that is sorted but it is not. :)
Just clear your cache and do this steps it should work anyway.
Comment this lines also
// if (!$cookieParams['httponly']) {
// unset($cookieParams['httponly']);
// if (!$cookieParams['secure']) {
// unset($cookieParams['secure']);
// if (!$cookieParams['domain']) {
// unset($cookieParams['domain']);
// }
// }
// }
//
// if (isset($cookieParams['domain'])) {
// $cookieParams['domain'] = $cookie->getDomain();
// }
Make sure you have cookies enabled in your browser, try a number of
different browsers including Safari or Opera. Chrome will give some
problems and you need to remember to clear you cache in Chrome after
making changes!
Make sure you file permissions are set to EVERYONE - FULL CONTROL for Windows and 777 for your Mac/Linux environment If all that still doesn’t work you can try this: (I do not recommend this solution for a production version of Magento, but for you local test enviroment this will work.)
Check the version of php you are using. If you are using recent Magento try to find which version of PHP and extensions requires.
More details
Did you erase the session storage in var directory?
In my case, when I was playing with autorization for multistore on subdomains (changed path and domain for cookie as you did), this method helped me to drop the "bad" cookie and sucessfuly logined in admin:
In apppath/var/session directory I've made command in shell (be careful with path, this could delete all the files in the directory)
rm -rf /path/to/magento/var/session/*
And then just clean the cookie for domain in browser.
I was fighting with this issue today on my local server. I couldn't login using any browser. I really didn't want to comment out any lines in core files or doing any other "dirty" solutions.
Firstly I checked cookie set by browser. It had expiration set to 1970, so clearly it was a cookie problem.
I checked values for cookies in magento database. In phpmyadmin I found table core_config_data, then fields with values : web/cookie/cookie_domain and web/cookie/cookie_path. They were both blank.
My solution was to set:
web/cookie/cookie_domain to my domain name
and
web/cookie/cookie_path to /.
Example:
your domain where you run magento is magento.local
set:
web/cookie/cookie_domain = magento.local
and
web/cookie/cookie_path = /
I never resolved the issue. But I wiped the clients computer and reinstalled windows 7, and it worked. It was very strange that it didnt work before as he was not behind a proxy, did not have ad ons or viruses. And the issue reproduced in each of his browsers (chrome firefox and IE). It was not a router issue. It was a windows issue, but I couldn't tell you what exactly was causing it. It was not the internet security settings either, as I checked those. Also checked the host file. As I said before, very baffling
I had the same problem, but I was working on XAMPP on windows 7 x64.
In Magento system - configuration - web - session cookie management change Use HTTP Only to no and Cookie Lifetime to 86400.
I only changed the Cookie Lifetime just in case of daylight saving time may not have to be changed.
Before the changes I could only login using Firefox and after the changes all browsers work.
Leave Cookie Path and Cookie Domain blank.
Check the cookie configs in core_config_data table and check if your session is being saved on db. In my case, someone just changed the cookie domain and the cookie path with a wrong value.
You can also check this on the node in your app/etc/local.xml.
If it's on db, maybe you should change do files to be able to clean the session data directly on var/session dir.
Delete cookies (related to your domain) from your browser setting.
I was facing the same issue and at the end i found that it was due to full disk space and due to this Magento was not able to create sessions file in the var var/session folder. After cleaning up log files that issue was resolved.
Also, you can update the password in the database if everything else from above didn't work and you need desperate access:
UPDATE admin_user SET password=CONCAT(MD5('qXpassword'), ':qX') WHERE username=‘user’;
replace user and password words according to your needs.
If nothing works, make sure the disk quota is not exceeded. The new session cookies created under ./var/session will be zero bytes length if disk quota for the user is exceeded.
In Case, that you dont see any cookie named "frontend" or "adminhtml", when you reload the page, the Magento cookie wasn't set. In my case I have a wrong cookie_domain.
I used "null" instead of "NULL".
As I set my cookie_domain to NULL in core_config_data, the problem was solved
We recently migrated our Multi-domain magento setup from a shared host to a dedicated server.
All is working fine fronted, but when I try to go to the admin section I get a 404 error on anything after login.
It seems to work if I remove index.php from the url but then as soon as I click on another link in the admin section it 404's again with the index.php back in the URL.
-- You need to go your server directly and do this via SSH/ FTP
You have to delete the following file
app/etc/use_cache.ser
If you get an error after that like
Notice: Undefined index: 0 in
/srv/www/vhosts/javra.com/htdocs/munchad2/app/code/core/Mage/Core/Model/Mysql4/Config.php
on line 92
Then go to your Database Management.
Open PhpMyAdmin
Go to your database
Click SQL
Run the following SQL Query:
_
SET FOREIGN_KEY_CHECKS=0;
UPDATE `core_store` SET store_id = 0 WHERE code='admin';
UPDATE `core_store_group` SET group_id = 0 WHERE name='Default';
UPDATE `core_website` SET website_id = 0 WHERE code='admin';
UPDATE `customer_group` SET customer_group_id = 0 WHERE customer_group_code='NOT LOGGED IN';
SET FOREIGN_KEY_CHECKS=1;
Some thing strange happens with the cache when you move the databases from one server to another so it seems like you need to clear it out.
Check in this way
> http://www.yourstore.com/index.php/admin/
or
> http://www.yourstore.com/admin/
After migration from www.domain1.com/magento/ to www.domain2.com/magento/
I was getting 500 Internal Server Error.
So I just renamed my .htaccess to htaccess.txt.
And my frontend started working fine,
But at Backend http://www.yourstore.com/admin/ I was getting Same 500 Internal Server error.
After trying many option suggested online nothing worked for me and after that I tried to access admin via following URL and voilà worked perfect, Hope this help others.
Try to access as this > http://www.yourstore.com/index.php/admin/
Does the dedicated server have mod_rewerite enabled? Does the apache configuration allow .htaccess files to make changes to configuration directives via AllowOverride? Both of those are common ways that the Magento config gets pooched up.
This is an old thread but I've also had an issue with ownership what was returning a 404 in admin.
I'd been doing some work on securing the server and some files were owned as root, not apache. So a chown -R apache:apache . fixed it right up.