Bug #22881: tx_saltedpasswords_sv1 should use parent object instead of TYPO3_MODE - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #22881

closed

tx_saltedpasswords_sv1 should use parent object instead of TYPO3_MODE

Added by Alexander Stehlik almost 14 years ago. Updated over 5 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

Target version:

Start date:

2010-06-15

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

4.4

PHP Version:

5.3

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

At the moment, tx_saltedpasswords_sv1 uses the TYPO3_MODE constant to determine in which table the password should be updated (in updatePassword() method).

This isn't very clean and can lead to problems if you use some kind of be/fe login combination extension like simulatebe. There, the user logs in to the Frontend, to TYPO3_MODE is "FE" but wants to authenticate a BE user.

A simple solution to this is the usage of the $pObj field. See the attached patch. It makes things much simpler and cleaner as far as I can see.

(issue imported from #M14727)

Files

patch_saltedpasswords_cleanup.diff (1.42 KB) patch_saltedpasswords_cleanup.diff

Administrator Admin, 2010-06-15 12:21

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Marcus Krause over 13 years ago

Dumping my comment from the core list here:

The patch doesn't solve the problem once and forever.

In tx_saltedpasswords_sv1::init() there's a function call to
tx_saltedpasswords_div::isUsageEnabled() which determines if
saltedpasswords is enabled for the desired TYPO3_MODE.

To completely fix this problem, you would hand over the mode somehow
retrieved from $pObj to tx_saltedpasswords_div::isUsageEnabled().

Luckily, isUsageEnabled() accepts an optional parameter with the TYPO3_MODE.
Unluckily, $pObj is not yet available at this state. It's available with
tx_sv_authbase::initAuth(), the next call in authentication service
instanciation/service.

Actions

Copy link