Bug #22141
closedFirst login attempt to the backend fails every time
0%
Description
I updated from 4.2 to 4.3.
The first attempt to log into the backend fails every time. - The second works well.
This problem is browser- und user-undependent.
I tried clearing the be_session-table and site-cookies, but it has no effect.
(issue imported from #M13582)
Updated by Steffen Ritter almost 15 years ago
Hey,
i cannot reproduce this issue.
I updated several instances from 4.2 to 4.3 and did not encounter this behaviour.
Do you have any extensions installed with authservices or an own login skin or sth. like this?
Updated by Marcus Krause almost 15 years ago
I'm able to reproduce this. However, it hasn't annoyed me too much. ;-)
It might be because I'm generally blocking cookies, only allow specific domains to set cookies and accept them for the browser session only.
Might be that I'll soon capture the according http requests/responses to find the cause of this behaviour.
Updated by Marcus Krause almost 15 years ago
@ the reporter:
Do you use rsaauth? (I do)
Updated by Benni Mack almost 15 years ago
I can sometimes reproduce this issue but it happens sporadically (without RSA, salted passwords etc). Can you provide some details when this problem occurs?
Updated by Andy Hausmann over 14 years ago
I can reproduce this bug as well.
It appears every first login attempt at the backend login page. I've never tested this for the frontend login.
I don't think this bug depends on an extension, becaus it apeared recently on a blank TYPO3 4.3.3-Installation just 5 days ago. Nothing has been configured so far.
Currently i am using Firefox 3.5.7 on Mac, but it also happens at Firefox 3.6, IE6-IE8 (IETester) (WinXP) and Safari for Mac.
Today i've found a posting at TYPO3-Jack.net: https://www.typo3-jack.net/typo3-english-lists-netfielders-de/24746-typo3-english-backend-first-login-attempt-fails-every-time-phpsessid-related.html
Christian Essl figured out, that TYPO3 creates the Cookie be_typo_user = 'value' at the first login attempt. Untill you try to login at the second time, TYPO3 creates the Session PHPSESSID = 'value'.
Maybe it could be important to know: TYPO3 4.4 alpha 1 does not have this problem/bug.
Updated by Felix Nagel over 14 years ago
I can reproduce this bug, too.
System:
TYPO3 4.3.3
Apache 2.2.9 (Fedora)
Register Globals disabled
PHP 5.2.6
Using:
rsaauth 1.0.0
saltedpasswords 1.0.0
felogin 1.3.0
Tested with:
FF 3.6.3 & 3.6.4Beta
IE 8
Opera 10.x
-> OS: Win XP Pro SP3
Appearance:
BE login fails every time, but FE login works pretty well. Both with rsa and salted passes.
Hope that helps. As this is a pretty annoying bug, I'm available as beta-tester :-)
Updated by Oliver Klee over 14 years ago
In my case, this seems to be related to cookies. I can reproduce the problem with these steps:
1. load the BE login page
2. clear the domain cookies
3. try to login
-> login failed
I can not reproduce the problem with these steps:
1. load the BE login page
2. clear the domain cookies
3. load the BE login page again (so that the cookies get set)
4. try to login
-> login succeeds
Updated by Johannes K over 14 years ago
We had the BE-Login problem with after an update to TYPO3 4.2 too, and it dissappeared when we uninstalled the phpmyadmin extension
Maybe related to:
http://bugs.typo3.org/view.php?id=10507
http://bugs.typo3.org/view.php?id=10467
Updated by Felix Nagel over 14 years ago
Bingo!
BE login works great and as expected if EXT phpMyAdmin is deinstalled.
Do we need a new bug report within phpMyAdmin?
Updated by Guido Unger over 14 years ago
it is not (or not only) phpmyadmin
t3-4.3.x and I cannot remember when, but it started on a customer website someday.
I uninstalled phpmyadmin but the prob persists.
I can confirm Oliver Klees post (0038927) same here, once the cookie is set, it workz.
problem still persits after upgrade to t3-4.4
on a clean t3-4.4 local on mac osx it workz perfectly.
Updated by Nando Bosshart about 14 years ago
We could reproduce the problem as well - and found a way to solve the problem:
It seems that the problem depends on the order in which the extension "phpmyadmin" is listed in $TYPO3_CONF_VARS['EXT']['extList'].
If "phpmyadmin" comes AFTER the entry "formhandler" the login fails on the first attempt. If the order is changed (.."phpmyadmin,formhandler,"..) then the login works as excpected on the first try.
Formhandler Version tested: 0.9.6 / 0.9.7
phpmyadmin versions tested: 4.8.0 / 4.9.0
Typo3 Versions tested: 4.4.x
Updated by Hannes Gesmann about 14 years ago
@Nando: Looks pretty good:
I simply changed the order (in localconf.php) and the first login works again!
Versions tested:
[TYPO3, formhandler, phpmyadmin]
4.4.2, 0.9.7 ,4.9.0
4.3.3, 0.9.7, 4.8.0
I wasn't able to reproduce this with formhandler version 0.9.8:
4.4.2, 0.9.8 ,4.9.0
So to me it looks like a formhandler bug...
Playing around leeds to the following:
After copying lines 49-63 in ext_tables.php to formhandler 0.9.8 the bug occurs again. These lines are:
if(!is_object($GLOBALS['BE_USER']) || !$GLOBALS['BE_USER']->checkCLIuser()) {
$GLOBALS['BE_USER'] = t3lib_div::makeInstance('t3lib_beUserAuth');
// New backend user object
$GLOBALS['BE_USER']->start(); // Object is initialized
$GLOBALS['BE_USER']->checkCLIuser();
$GLOBALS['BE_USER']->backendCheckLogin();
$GLOBALS['BE_USER']->fetchGroupData();
// set proper be configuration
$GLOBALS['BE_USER']->warningEmail = $TYPO3_CONF_VARS['BE']['warning_email_addr'];
$GLOBALS['BE_USER']->lockIP = $TYPO3_CONF_VARS['BE']['lockIP'];
$GLOBALS['BE_USER']->auth_timeout_field = intval($TYPO3_CONF_VARS['BE']['sessionTimeout']);
$GLOBALS['BE_USER']->OS = TYPO3_OS;
}
I just don't now what phpmyadmin has to do with this, yet.
Updated by Dmitry Dulepov over 13 years ago
- Status changed from Needs Feedback to Closed
- Target version deleted (
0)
Seems like it is not a core issue.