Feature #46246
closed
Possibility to deactivate some checks in reports extension
Added by Bernhard Eckl over 11 years ago.
Updated over 11 years ago.
Priority:
Won't have this time
Description
The reports extension checks for Backend user password hashes if the extension saltedpasswords is installed. But if also using eu_ldap, you always get the message:
[ERR] Backend user password hashes - Insecure
(because eu_ldap adds in the password field of the ldap account some random chars as dummy, so the passwords don’t look like a salted password)
I have also seen something in the mailing list about that issue:
http://lists.typo3.org/pipermail/typo3-german/2011-December/082058.html
So for this (or also similar issues) it would be very helpful if some checks could be deactivated via extension settings.
I commented the lines 250 to 286 out, to get rid of this.
- Status changed from New to Needs Feedback
I guess it's not the core's fault that there is "garbage" in the password field of the users. Some users might be logged in through TYPO3 password mechanism still and the "garbage" created by eu_ldap won't allow the core to differenciate it from non-salted passwords.
A solution would be if eu_ldap adds a "$" in front of the garbage it stores in the field. This would bypass the "insecure password" check of the reports module.
Disabling that check would make you not notice if for example "admin" (not LDAP user) is still using old-school md5 passwords.
What do you think?
Yes, that would work. Another option would be that reports automatically detects the ldap users and excludes them when running the check. An ldap user could be detected if there is some entry in the tx_euldap_dn field of the feusers and beusers table. At best if both variants would get implemented.
- Status changed from Needs Feedback to Rejected
- Priority changed from Should have to Won't have this time
This is very extension specific, and there are other extensions providing other kinds of authentication methods. The TYPO3 CMS Core should not make extension specific handlings.
If the reports module doesn't make sense for eu_ldap (or any other authentication extension), there is always the possibility of XCLASSing the class that does this particular check and provide an alternative.
So I'm closing this at first with "Won't fix" (in the Core), and expect extensions to either adapt itself to this module, or suggest some kind of hook for the reports module that would make their lives easier, if required.
ignore my vote, clicked that by accident...
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by