I had the following issue with my installation of ISPConfig 3.1 (recently upgraded): When attempting to login, by entering the host name on the address bar, (ie. https://vps.mydomain.com:8080), login gets stuck in a loop, continuously reloading the login screen, even though the password is correct. However, if I reach the admin site by IP address such as https://10.10.10.126:8080, the login works fine. I did 2 upgrades on 2 different machines, with the exact same result. Then, I thought it was because of the upgrade, so I created a brand new installation, using the tutorial here , and the result was exactly the same. Anyone have any ideas what may be going on here? Best regards.
The inspector is telling me that several files are not found. Again, this is NOT because of an upgrade. It happens on a brand new fresh installation as well.
It is not viable to do such thing every time we want to log in Edit: possible solution to the problem is when the first login attemp failed, paste the following code in the address bar (don't forget javascript word at the beggining of the line). javascript: (function(){C=document.cookie.split("; ");for(d="."+location.host;d;d=(""+d).substr(1).match(/\..*$/))for(sl=0;sl<2;++sl)for(p="/"+location.pathname;p;p=p.substring(0,p.lastIndexOf('/')))for(i in C)if(c=C){document.cookie=c+"; domain="+d.slice(sl)+"; path="+p.slice(1)+"/"+"; expires="+new Date((new Date).getTime()-1e11).toGMTString()}})() This code deletes every cookie in the active tab. I did it and worked fine
Nobody asked to do it every time, you shall clear the cache once after you updated from 3.0 to 3.1 because the problem is caused by cached ispconfig 3.0 js code.
I can confirm clearing the cache works with a new install, but it does not always work with an updated installation.
It works on an updated installation as well, you just have to ensure that you removed the cookies as well in cae that you were logged in during update.
Yes, both cache and cookies were removed. Result is the same. Works on fresh installation, does not on updated. Not even the jscript provided by borekon works. However, this behavior seems to only be happening on latest Chrome. The Edge browser has no problems.
In Chrome, I have found this works. Pull up the developer tools (Inspect Element) and go to the Application tab. Under the Application category, choose Storage, and clear everything. It only does it for the site which is good. For some reason, doing the global Clear of Cache and Cookies is not working correctly.
Good Morning, I'm going through this situation in all browsers. Even clearing the cache in browsers, after a few minutes the login loop again. I am using Debian Jessie with apache and php-fpm.
Good Morning, I did differently. I entered the menu: interface / main config. And on the MISC tab I unselected the following options: Use jQuery UI Combobox and Use Load Indicator. Now the login works fine. I think it has some bug with the components JQuery UI Combobox and Use Load Indicator that cause the login loop
Guys this might seem a bit... of an ignorant and somewaht necro of a post but, I encountered a similar issue and after reading THIS post anddddddddddd reading THIS post : https://git.ispconfig.org/ispconfig/ispconfig3/issues/4013 I nearly had a heart attack I was thinking ok, what did I do just before this happened. Surely I don't have to practically rewrite an object oriented javabean to make this work again, all I'd done was created another domain website and created a new table for a wordpress database... surely this wasn't some kind of rocket surgery I also didn't want to start messing around with the /etc/my.cfg or play with any of the other stuff because I knew I could break more.. I was like ok, what do I do to fix this, I mean, literally having had zero prior experience I was a bit confused. Soooooo I slowly started piecing together what had happened is the sys_session part of the database had crashed I paid more attention to the exceptional Till Brehm's post Till Brehm @tbrehm commented 7 months ago Owner Sessions get saved to the database and never to the /tmp folder. What you did is that disabled the database handler, s if the database handker fails then you have a problem with your database in general or the sessions table. Your issue is not a bug and not reproducable on other servers, its a local problem on your server more specifically... you have a problem with your database in general or the sessions table So I went into mysql which I could still access. Then selected the ispconfig.db wanted to work out if it was general or session area that was problematic. as soon as I clicked on sys_sessions it told me it had crashed and needed to be repaired. again, no knowledge or prior experience just started thinking ok what's the go.. few more moments with google. I found this https://stackoverflow.com/questions/4357270/table-is-marked-as-crashed-and-should-be-repaired Soooo after I put a check next to sys_session selected repair table and ET VOILA BOOM BABY we're back in. no more loop. I really am hoping that in the revelry of overcoming my ignorance someone else saves a few seconds or learns something new!
