TYPO3 Core

I have users complaining too that often (but not always) the first login fails (using saltedpasswords/rsaauth). After reloading the login form it works. This is not a new issue - at least for 4.5.15 and 4.6.8 it was reported too.

i know that this issue is known, but i can't find the related issue. as this is bothering me, i also suggested a solution... (load and refresh the key via ajax)

Others have the problem as well:

http://www.typo3-media.com/blog/website-caching-login.html

Do you see any chance to get that issue voted up?

Regards
Kay

I think the key should be loaded by ajax right before the form is submitted. By doing so it is not necessary any more to load the key at a regular basis.

I just verified the issue on a 4.7.1 installation with rsaauth + saltedpasswords (loginSecurityLevel = rsa).

The following steps are reproducable (Tested with Chrome to verify the noted steps below, but it also happens in Firefox, never logged in to that BE with Chrome before):
- Open a tab, navigate to foobar.tld/typo3
- Enter Username/Password and submit
Login fails + Form is shown again
- Enter Username/Password again and submit
Login success!
- Logout from Backend

Above steps can be reproduced after logout (2 rounds needed to be logged in)

I then also tried whether saving the credentials in the browser changes the behaviour - it doesn't. Also when Chrome prefills the form, I have to submit it two times to get logged in to the backend.

I had the impression that I had a similar (if not identical) behaviour also in 4.5.x - but never found a way to reproduce it consistently (and it happened every few days, in different installations - randomly). Now in 4.7.x it's reproducable consistently.

Mario Rimann wrote:

Above steps can be reproduced after logout (2 rounds needed to be logged in)

I had the impression that I had a similar (if not identical) behaviour also in 4.5.x - but never found a way to reproduce it consistently (and it happened every few days, in different installations - randomly). Now in 4.7.x it's reproducable consistently.

I cannot reproduce it on a clean 4.7.1 install. Do you have phpmyadmin installed on that installation? This extension messes with the PHP session, resulting in the described behaviour. If not phpmyadmin, any other extension that does some weird session handling?

no phpmyadmin @all review, but some caching options enabled in apache.

login works smooth for me with rsaauth disabled, but is always blocked once with rsaauth. This also happens, if the loginpage is loaded in a background tab and used after some hours ;) - (timeout)

Yes, on those websites phpmyadmin is installed and indeed this was the cause for the problems! After uninstalling phpmyadmin the login works again on first try. So this should be filed as a phpmyadmin-bug?

Helmut Hummel wrote:

I cannot reproduce it on a clean 4.7.1 install. Do you have phpmyadmin installed on that installation?

I can confirm that on the same installation where I tested this problem a few days ago (see above), removing phpmyadmin + clearing caches solved the problem. I'm now able to login directly to the BE without problems.

Thanks for the hint with phpmyadmin - now I have the last reason to remove this extension once for all, ...

Hello,

I had the same problem of failing first identification on 4.7.2 installation. After reading this issue report, I have uninstalled the phmyadmin extension and I confirm it fixed the issue.

So it is likely the secured authentification code of this extension is interfering with the Typo3 authentification process. I figure phpmyadmin extension's security has been worked a lot for Typo3 because Phpmyadmin has proven in the past to be a wonderfull backdoor with its security breaches. But the authentification communication between Typo3 and phpmyadmin has been buggy for quite a year now : often when you would click on the phpmyadmin module title in the left column, you would have an authentification error in the right panel. In this case you have to reload the whole backend in your browser to be authentified and have phpmyadmin to show up. So it is likely phpmyadmin's authentification code does require some tweaking.

I've the same problem but without having phpmyadmin installed. I figured out that in my case felogin is causing the problem. So after uninstalling felogin, restarting Firefox, clearing its cache I can login with the first try.

I can confirm this issue with two installations one with 4.7.1 and the other with 4.7.2 installed. So now I don't know if this is still a rsaauth-related problem or if we should change the category of this issue to "felogin". Or shall I open a new bug-report for felogin?

Michael

it's rsaauth related - rsaauth should fetch the key via ajax directly before login ... thanks for sharing your thoughts and problems ;)

On a 4.7.3 installation I'm having the same problem with the first FE-login (not with BE-login), but removing phpmyadmin didn't helped. Not even with the new version 4.14.0 published at 2012-08-13 which fixed the BE-login problem (http://bugs.typo3.org/view.php?id=18560). But I found that this bug only occurs if I'm trying to login right after logout. If I go to the login-page using the menu the login works at the first try.

Any news on this issue? I don't think it's "enterprise" to let hundreds of users try to login two times so let's do something here. :)

If this is not fixed yet I'd like to do some sponsoring on fixing that issue. If my sponsorship won't be enough for the effort of fixing that bug I'd be happy if others would sponsor some money, too.

Btw. I miss the "sponsor-feature" in Redmine we had in the old bug-tracker. :)

Hi, I am also experiencing this problem in at least one installation of a client. And it is also reproducible in my local testing environment.

The problem occurs if you logout and want to login right away. Then it seems as if the RSAAuth information in the session gets messed up:

Step 1: user logs in, everything is fine. The private-key used for the login was generated and has the ID 1)

Step 2: user is logged in, user hits "logout"

• the RSAAuth extension creates a new key-pair and stores one part of the private in the session and the other part into the database. The session also contains the key-pair-id (let's say the id is 2)

Step 3: user wants to login again.

• problem: the session that gets loaded still contains the private-key-id 1 as if the new key would not have been created. But the public key that was used for encrypting the users credentials belongs to id number 2.

So somewhere between step 2 and 3 the session does not get stored correctly. This is absolutely weird. Maybe someone with deeper knowledge in the PHP session handling and the RSAAuth-extension should have a look into this. I'll continue digging, over the next days as time permits.

Just another case for the record (using 4.5.19 LTS on Chrome 22)

- Log in (after 2nd try)
- Go to direct_mail
- It logs me out
- Log in again
- Go to direct_mail
- Now I can work

These extensions are installed:

$TYPO3_CONF_VARS['EXT']['extList'] = 'css_styled_content,info,perm,func,filelist,about,tsconfig_help,context_help,extra_page_cm_options,impexp,sys_note,tstemplate,tstemplate_ceditor,tstemplate_info,tstemplate_objbrowser,tstemplate_analyzer,func_wizards,wizard_crpages,wizard_sortpages,lowlevel,install,belog,beuser,aboutmodules,setup,taskcenter,info_pagetsconfig,viewpage,rtehtmlarea,t3skin,t3editor,reports,felogin,linkvalidator,recycler,t3filelist,realurl,ke_search,realurl_clearcache,image_autoresize,tsconf,sourceopt,tscobj,naw_securedl,saltedpasswords,scheduler,additional_scheduler,kickstarter,formhandler,braem_oda_filelist,braem_oda_wb,css2inline,braem_oda_jobs,tt_address,direct_mail,df_direct_mail_subscription,nc_staticfilecache,it_dmailer_htmlfix,rsaauth,scriptmerger';

Like Michael Bakonyi I would also be glad to pledge a little sponsoring for this issue. but how? Would be cool if there was a kickstarter (not the TYPO3-Kickstarter :-) like functionality...

I also observe this bug, with the same remarks as Sebastian: there is a shift of key number, which makes rsaauth unable to decrypt the password. After reloading the page one or more times, the login finally works.

I haven't been able to find the issue. It's really weird. Actually of all the sites I work on, it's the first time I get it. So it's quite obvious that it depends on server settings, maybe PHP, maybe also due to a proxy (that client uses a proxy and we get or not the mistake depending on whether the server is behind the proxy or not). I'm not expert enough in session storage (and possible influence by server/PHP settings or proxies) to know where to start digging.

Knowing what the problem is would of course help making rsaauth more solid.

Using a current version of phpmyadmin (v.4.14.0) the login error on first try is fixed.

Hi all.

I've also recently faced same problem and it was site-specific in my case.
You may look at reason here: Bug #38660

Maybe, that may help someone :)

Stephan Großberndt wrote:

Yes, on those websites phpmyadmin is installed and indeed this was the cause for the problems! After uninstalling phpmyadmin the login works again on first try. So this should be filed as a phpmyadmin-bug?

On my site, it used to be also a conflict with phpmyadmin (v. 3.5.2). Renaming the phpmyadmin directory to a non-standard name solved the problem! It seems phpmyadmin uses the same RSAAuth token.
My working example can be found here: http://www.wellness-heaven.net

However, reading the posts above, the bug seems to appear also on sites which do not use phpmyadmin at all. Try searching for other instances of RSAAuth ...

i also had that problem in installations with no phpmyadmin installed.

• somtimes the login fails due to caching problems.
• sometimes the caching fails if the user has opened the login page for hours and the rsa key expired

Both problems can be solved, by fetching a new rsa key if there is a onblur on the username or before submitting the form.

On the current site rsaauth is not working at all.
I installed felogin, put it as Content-Element on one page and have additionally a modal-box on each page that is shown by click on a login-button.
Maybe the double usage is the reason, but usually the user never sees the login-page but only the modal-box.

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28893

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28893

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28893

Are these changes in version 4.5? Or it is planned to apply the changes there?

thanks