Bug #23625
closed
globalVar = TSFE : beUserLogin > 0 is only true for BE admin users
0%
Description
- something
...
only works for logged in BE admin users. I'm not sure if this is intentional, but it looks like a bug to me. I've been looking into this for hours and there doesn't seem to be a way to identify if a non-admin BE user is logged in.
I can reproduce this on 4.2.12 and 4.4.1.
(issue imported from #M15827)
Updated by Nicolas over 13 years ago
Can be reproduced on 4.4.2 and 4.2.0 as well.
I'm sure I must be missing something really obvious here. Having a TS conditional for logged in BE users looks absolutely trivial. So I apologize if this should really be a support question.
The backend users are logged in and this behaviour is very easy to reproduce.
Updated by Nicolas over 13 years ago
This behavior seems to be caused around line 339 of typo3/sysext/cms/tslib/index_ts.php
This looks like a bug to me. Having access right should not affect a variable called beUserLogin.
// Now, if there is a backend user logged in and he has NO access to this page, then re-evaluate the id shown!
if ($TSFE->beUserLogin && (!$BE_USER->extPageReadAccess($TSFE->page) || t3lib_div::_GP('ADMCMD_noBeUser'))) { // t3lib_div:: _GP('ADMCMD_noBeUser') is placed here because workspacePreviewInit() might need to know if a backend user is logged in!// Remove user
unset($BE_USER);
$TSFE->beUserLogin = 0;
Updated by Alan Frost over 13 years ago
This problem also appears to affect 4.3.4 with PHP 5.2.4.
Updated by Steffen Gebert over 13 years ago
Has the user really (at least) read access to the page opened in FE? (can he see the page in BE?)
To me the if-clause sounds reasonable: If a BE-user has no access rights to a page, he should not be in the same context as BE users, having access to the specific page.
Updated by Alexander Opitz over 10 years ago
- Category deleted (
Communication) - Status changed from New to Needs Feedback
- Target version deleted (
0) - Is Regression set to No
Hi,
as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (4.5 or 6.1)?
Or did you find another way to achieve what you need?
Updated by Patrick Kroog over 10 years ago
Alexander Opitz wrote:
Hi,
as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (4.5 or 6.1)?
Or did you find another way to achieve what you need?
I just noticed this case in 4.5.
I tried:
[globalVar = BE_USER|user|uid > 0]
[globalVar = TSFE : beUserLogin > 0]
Both of them don't work.
In my case "giving access to the page for the backend-non-admin" helped, like Steffen mentioned. But there might be other cases where this is not an option.
Updated by Alexander Opitz over 10 years ago
- Category set to TypoScript
- Status changed from Needs Feedback to New
Updated by Andre Michels about 10 years ago
Bug is still there. Version 4.7 is affected too.
In Addition:
Its no TypoScript problem. The whole $GLOBALS['BE_USER'] object is null if the BE_USER is no admin user.
Hotfix:
if(!is_object($GLOBALS['BE_USER'])) {
$GLOBALS['BE_USER'] = t3lib_div::makeInstance('t3lib_tsfeBeUserAuth');
$GLOBALS['BE_USER']->start();
$GLOBALS['BE_USER']->backendCheckLogin();
}
Updated by Stefan Neufeind about 10 years ago
- TYPO3 Version changed from 4.2 to 6.2
This was originally logged against 4.2. I've just tested this still occurs on 6.2 (so I'm updating this as the issue is still current). Maybe we can get a solution at least for the 6.2-branch?
Workaround is to create a userFunc (which can then be used in TypoScript) with something like:
if (!isset($GLOBALS['BE_USER'])) {
\TYPO3\CMS\Core\Core\Bootstrap::initializeBackendUser();
}
if (is_object($GLOBALS['BE_USER']) && !empty($GLOBALS['BE_USER']->user['uid'])) {
return TRUE;
}
return FALSE;
Updated by Alexander Opitz almost 10 years ago
- TYPO3 Version changed from 6.2 to 4.2
The TYPO3 field holds the value of the TYPO3 version this issue was first found/feature was requested. So back to 4.2
Updated by Patrick Kroog almost 10 years ago
Are there any other options without userFunction to do this?
This might be needed for previewing new settings, or disable Google Analytics for Admins & Editors..
If you just want to preview things "locally", this is a quick method without userFunction
/ * * * DON'T USE THIS FOR PRODUCTION SYSTEMS, as this is NOT safe * * * /
[globalString = _COOKIE|be_typo_user = /.+/]
...
[end]
Updated by Andy Schmidt about 9 years ago
- Project changed from TYPO3 Core to 1911
- Category deleted (
TypoScript)
Updated by Andy Schmidt about 9 years ago
- Project changed from 1911 to TYPO3 Core
Reproduced that $GLOBALS['BE_USER'] is NOT instantiated in FE, unless the currently logged on Back-End user happens to be an Administrator, contrary to documentation.
Confirmed the hotfix posted in entry number 8 to work-around this bug.
Updated by Riccardo De Contardi over 8 years ago
- Status changed from New to Needs Feedback
- TYPO3 Version set to 6.2
- Is Regression set to No
I did a test on both 6.2.15 and 7.6-dev (latest master) with the following code:
[globalVar = BE_USER|user|uid > 0] page.8=TEXT page.8.value=HI I am logged [global] [globalVar = TSFE : beUserLogin > 0] page.9=TEXT page.9.value=Hi I am logged 2 [global]
and I logged with a non-admin user: the result is that both strings are visible.
Could you check again, and confirm? Thank you.
Updated by Riccardo De Contardi over 8 years ago
- Status changed from Needs Feedback to Closed
No feedback within the last 90 days => closing this issue.
If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.
You could also join the #typo3-cms channel in Slack if you still need support.
Thank you
Updated by Anonymous over 7 years ago
For TYPO3 >= 6.2: as long as the backend user has read access to the current page both TSFE:beUserLogin and BE_USER:user are set correctly.
For pages without read access the workaround that worked for me looks like:
if (!isset($GLOBALS['BE_USER'])) {
$GLOBALS['BE_USER'] = $GLOBALS['TSFE']->initializeBackendUser();
}
Not sure what the side effects are though.
The whole issue might be related to #45625.