Sporadic redirects on secondary magento store page - magento

Recently transferred my Magento 1.7 store to a new host, and started having a frustrating problem.
We've got the store sitting behind a login shell - you can see it at http://www.seacadetshipsstore.com. Base exchange takes you to the root store (/magento/), and the gearlocker login takes you to a secure sub-store (/magento/gearlocker/).
The problem is, ever since transferring to the new host, /magento/gearlocker/ is sporadically redirecting to /magento/. I can only reproduce it 1 in every 10 times, but customers are constantly complaining that they can't access the secure store for this reason.
I've also noticed that if I turn off the security and have clients navigate to /magento/gearlocker/ directly, it seems to fix the problem for most - they no longer get the redirect after logging in. Only a few of them still have the error, and they're all PC users on various browsers.
I've set up a demo login for stack:
https://www.seacadetshipsstore.com/login.php
U: stack_login
P: thanks
I doubt it's an issue with the base url or base link url, otherwise the error would be much more consistent. I've gone through magento's official tutorials and made sure the secondary store was set up properly (remember, it was working fine on the old host). I also know it's not anything to do with the login shell - all it does is validate the user's login and redirect to /magento/gearlocker/.
Can anyone reproduce this error? Can anyone tell me what's going on, or how I might fix it? Thanks in advance!

Related

Can't log into Joomla frontend

So we just started a website (poweronfilms.com). We only have 2 accounts so far. Josh (the superuser) and me. I am marked as an administrator. For some reason, every time I try to log into the frontend, it just reloads the page. If I put in false credentials, It tells me I have the wrong username/password. But If they're correct, it doesn't do anything. I can still log into the backend just fine though, and it tells me I'm logged in to the site, but I can't access it. Our superuser can still log on.
The most probable reason that it gives error for wrong credential but for valid credential it's not allowing you to login is might be because you have set wrong cookie domain in configuration.php
public $cookie_domain = '';
Recheck that setting, if it points to correct one or try with blank.
There's a myriad of reasons of why you are redirected back to the login page without any error, it might be:
Unwritable tmp and/or logs folder
Non-empty cookie domain
Forced caching in the .htaccess file (see here )
Invalid session handler
The above list is not exhaustive.

Stage environment for Magento for dummies - 500 internal server error

I'm brand new to server side setup and creating staging environments. I have a magento live environment I've setup, but now I want to setup a stage environment (stage.mystore.com) and practice rolling from stage to live. But, I'm a newb to this and having issues.
I started by following this tutorial to the T, but am currently stuck:
http://www.crucialwebhost.com/kb/setting-up-a-magento-staging-area/
I can load my homepage on the stage subdomain, but any link I click on gives me an "500 internal server error". Secure and unsecure.
I've read around a lot, and it seems like I probably need to either edit something else in my .htaccess or core_config_data but I'm uncertain what to do next.
Can anyone provide more complete step by step instructions for this last part for me?
PhilB's response worked. I just needed to do that change to the varien.php file AND clear out all cookies from my live server in my browser and then I could login. thanks.

codeigniter session data gets lost

i already posted this question but still wasnt able to resolve this issue.
seems that everyone has this problem with codeigniter .
When i set my session in a controller it works perfectly and i can display it.
WHen i move to another controller, the (CUSTOM) session data is completely lost.
i tried changing my cookie_domain in config.php. Since i am on localhost i tried localhost with without / and localhost/codeigniter and sodeigniter all did not work. i am lost
btw, i read somewhere that this happens when 2 ajax requests happen at the same time. could that be the problem?
Or maybe tell me how you resolved the problem if you had same issues
screw this, i am swithing to php native sessions. if anyone wants to do that,
http://codeigniter.com/wiki/PHPSession
Check and double-check your code or any external libraries you are using for a stray sess_destroy(). I ran into a similar problem where I was storing an id in the session for reference but if the user then logs in the SimpleLogin library I was using for logins just destroys the entire session including data I did not want to lose.
This is what I get for not writing my own code.

Can't login to Magento admin

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

MOSS search crawl fails with "Access is denied ..."

Recently the search crawler stopped working on my MOSS installation. The message in the crawl log is
Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)
The default content account is an admin on the site collection that I am trying to crawl.
Almost every result for this error on Google tells me to add the DisableLoobackCheck registry key with a value of 1. I have done this and rebooted and the error continues.
The "Do not allow Basic Authentication" checkbox in my crawl rule screen is unchecked.
Is there anything else that could be causing this error? Something with file system or database permissions maybe?
Edit: All signs seem to indicate that the "DisableLoopbackCheck" should fix this, but it doesn't seem to work. Could I be doing something wrong when I enable this?
I'm doing it in My Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, where I create a new DWORD key called DisableLoopbackCheck and give it the hex value 1.
It turned out not to be related to DisableLoopbackCheck. The problem was that the search was accessing the site through its external URL. You are supposedly not supposed to be able to access a site from within a server using the same URL that you use to reach it from the outside, at least in pre-SP1 MOSS. But I was doing this for about two years somehow. MS Support tells me they don't quite understand how it was ever working. So it looks like I ran into an issue that should have been manifesting all along. I'm not sure what caused it to appear suddenly, maybe some routine patching of the server. The solution was to extend the web application so it was accessible internally through the machine name, then point the crawler at that.

Resources