Bug #91049
closed
PageResolver has no info about feUserGroup to properly do $site->getRouter()->matchRequest which leads to 404 for records that are fe_group protected
100%
Description
HOW TO REPRODUCE:
1. Setup ext:news
2. Setup routing configuration for ext:news
3. Setup frontend user login and log to website
4. Set some news to be avaliable only for logged users (fe_groups)
5. The news will be visible on list view but when you click single news link you will see 404 error
THE REASON:
The reason is that router matcher can not read record because wrong frontend group are returned by GeneralUtility::makeInstance(Context::class)->getAspect('frontend.user') because user->groupData is not yet filled at this time.
MORE INFO:
In file typo3/sysext/frontend/Classes/Middleware/PageResolver.php at line 111 there is check for:
$pageArguments = $site->getRouter()->matchRequest($request, $previousResult);
Inside this check there is query that use TYPO3\CMS\Core\Database\Query\Restriction\FrontendGroupRestriction. In the constructor of the FrontendGroupRestriction there is
$frontendUserAspect = GeneralUtility::makeInstance(Context::class)->getAspect('frontend.user');
This $frontendUserAspect has method getGroupIds() which use isLoggedIn() which checks for $this->user->groupData['uid'] but on this level there is no yet $this->user->groupData because it will be generated in file typo3/sysext/frontend/Classes/Middleware/PageResolver.php at line 158 $this->controller->determineId()
Updated by Gerald Aistleitner almost 4 years ago
I can confirm this. Worked for 9.5.14.
Updated by Krystian Szymukowicz almost 4 years ago
- Subject changed from PageResolver has no info about feUserGroup to properly do $site->getRouter()->matchRequest whicih leads to 404 for records that are fe_group protected to PageResolver has no info about feUserGroup to properly do $site->getRouter()->matchRequest which leads to 404 for records that are fe_group protected
Updated by Benni Mack almost 4 years ago
- Target version set to next-patchlevel
- Is Regression set to Yes
Updated by Benni Mack almost 4 years ago
- Status changed from New to Needs Feedback
The reason why this is currently the case is that the fe_group is not found at this point. it is currently highly coupled to $TSFE->determineId() where groups are detected and modified based on the page that was found. For this reason the final information on the groups can only be found after the TSFE-initialization middleware has been run.
This was always the case like that and if we modify this a lot of hooks would be not working as expected anymore. That's why we can only change this in TYPO3 v11.
However, in this case, the Aspects (could you share your enhancer configuration) should not consider FE Group Restrictions anymore, is that correct?
Updated by Gerrit Code Review almost 4 years ago
- Status changed from Needs Feedback to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64408
Updated by Gerrit Code Review almost 4 years ago
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/c/Packages/TYPO3.CMS/+/64408
Updated by Krystian Szymukowicz almost 4 years ago
Exactly. If Aspects will not consider FE Group Restrictions the all will work as expected.
Updated by Benni Mack almost 4 years ago
Krystian Szymukowicz wrote:
Exactly. If Aspects will not consider FE Group Restrictions the all will work as expected.
Perfect Krystian. If you could vote on Gerrit (log in to gerrit with the same credentials as on forge.typo3.org, click on the blue "Reply" button https://review.typo3.org/c/Packages/TYPO3.CMS/+/64408 and vote for this patch to go in for the next version).
Updated by Gerrit Code Review almost 4 years ago
Patch set 1 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64358
Updated by Benni Mack almost 4 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 99af82fb0198302a69d49b0452d804ee0f10d46c.
Updated by Benni Mack almost 4 years ago
- Status changed from Resolved to Closed
Updated by Christian Kuhn over 3 years ago
- Related to Bug #90989: Lookup of access restricted records throws 404 added