pcarrisalez Posted May 26, 2011 Share Posted May 26, 2011 I have researched this for the past two days on your site. I am at godaddy on windows/shared hosting iis7 php5.I have made the modification to cookie.php to remove ip checking as described in other posts, but the problem persists.When I setup I used ie8, the cookie seems to be set and isloggedback() fires off and I get to the backoffice.Trying to get my client into the backoffice had failed with a looping login, so I tried firefox and firefox login failed and showed me the loop my client was seeing.I am concerned about possible .htaccess file or php.ini file configurations from what I have read elsewhere as i do not know where to find these on godaddy hosting or how to properly configure these.I have been trying to follow the flow of the code and am severly confused why index.asp instantly redirects to login.asp without running any commands from index.asp. (I am using echo/script/alerts to notify me where the code is.) I do not know where the cookie/user/password validation happens that determines login.php needs to be executed.I have alert commands in the islogged() and isloggedback() functions that never execute during this looping error. I have also tested the cookie object, and am guessing since the object sets properly that the actual writing of the cookie might not be working properly, although I do see the cookie when I check the firefox cookies.Can anyone help with where the redirects are coming from, .htaccess and php.ini file setup in my godaddy environment, or how I can test if my cookie is getting set correctly (which most likely points to when the redirects are firing)?P.S. - This site is working just fine on my hosting at uplinkearth.com. I created a new database, exported from uplinkearth and imported to godaddy. Then I Modified the config file, changed permisions, and uploaded everything to godaddy from uplinkearth. It all works through IE8, but I am afraid to clear my IE8 cookies for fear I will loose backend conectivity completely on the production version at godaddy.My client is waiting on this, and it looks really bad. Please help. Link to comment Share on other sites More sharing options...
pcarrisalez Posted May 28, 2011 Author Share Posted May 28, 2011 I switched godaddy over from windows to linux hosting which did not solve the issue alone, but I did a fresh blank install of prestashop 1.3.7Then an export with replace of the product, module, and category tables (there were other tables but I made sure to leave employee and other non content based tables alone) from my database that was setup, and imported them into the fresh copy. Made sure the permissions were set correctly.Then replaced the freshly installed img and module directories with my old data. Of course, I moved my custom theme directory to the newly installed themes directory and it is day two and everything appears to be in order. Link to comment Share on other sites More sharing options...
pcarrisalez Posted May 28, 2011 Author Share Posted May 28, 2011 i am still curious how prestashop knows when to redirect to login.php.I never found in the code where it commands the redirect. Does it have something to do with ajax or some other server based technology? Link to comment Share on other sites More sharing options...
samarh32 Posted August 29, 2011 Share Posted August 29, 2011 Hi all I'd like to share my experience. I have been facing a login loop on my admin back office (isloggedback did not work correctly) for a week now after I uploaded my prestashop to my live server. Could not know why but at last, I found that the base path of my shop in /config/setting.inc.php was define('__PS_BASE_URI__', './'); I replaced "./" by "/" and it worked. I have no more login loops. taraaaa.... hope this helps.... Link to comment Share on other sites More sharing options...
nickb Posted November 18, 2011 Share Posted November 18, 2011 define('__PS_BASE_URI__', './'); I replaced "./" by "/" and it worked. I have no more login loops. This actually helped me on my login issue. Except mine read define('__PS_BASE_URI__', '//'); I simply deleted the superfluous '/' Now if I could only get the rest of my evening back after dealing with this mess. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now