Project

General

Profile

Actions

Feature #46246

closed

Possibility to deactivate some checks in reports extension

Added by Bernhard Eckl over 11 years ago. Updated over 11 years ago.

Status:
Rejected
Priority:
Won't have this time
Assignee:
-
Category:
Reports
Target version:
-
Start date:
2013-03-13
Due date:
% Done:

0%

Estimated time:
PHP Version:
5.2
Tags:
Complexity:
Sprint Focus:

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.

Actions #1

Updated by Ernesto Baschny over 11 years ago

  • 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?

Actions #2

Updated by Bernhard Eckl over 11 years ago

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.

Actions #3

Updated by Ernesto Baschny over 11 years ago

  • 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.

Actions #4

Updated by Ingo Renner over 11 years ago

ignore my vote, clicked that by accident...

Actions

Also available in: Atom PDF