Bug #91397

PersistedAliasMapper: 404 error when linking to a detail page and linked data item is outside webroot

Added by cosmoblonde GmbH 9 months ago. Updated 9 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Link Handling, Site Handling & Routing
Target version:
Start date:
2020-05-14
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
Tags:
pending-close
Complexity:
Is Regression:
Sprint Focus:

Description

Hi,

due to commit https://github.com/TYPO3/TYPO3.CMS/commit/2a1bda4f7dd33dfdcd0782afd49924925a623511 it is no longer possible (since v9.5.16) to link to a detail page if the linked item is outside the webroot.
The links are generated correctly but will return a 404.

The links are configured in the site configuration yaml file as routeEnhancers using the PersistedAliasMapper.

MyDataType:
    type: Extbase
    extension: cb_test
    plugin: CB_Test
    routes:
      -
        routePath: '/{title}'
        _controller: 'Test::show'
        _arguments:
          title: idOfMyItem
    defaultController: 'Test::show'
    aspects:
      title:
        type: PersistedAliasMapper
        tableName: tx_my_test
        routeFieldName: path_segment

The detail page is within the webroot.

I have custom datatypes outside my webroot in a sysfolder. If I move the folder into the webroot, links work correctly again.

The issue is caused by the function call filterContainedInSite on line 239 in /typo3/sysext/core/Classes/Routing/Aspect/PersistedAliasMapper.php

This function is defined in /typo3/sysext/core/Classes/Routing/Aspect/SiteAccessorTrait.php and checks if the PID is inside the current site.

With multi-site installations that are using data items from a single folder for several webroots, moving folders is no solution.

Can you please adjust the PID check or add an additional configuration parameter to disable that check?


Related issues

Related to TYPO3 Core - Bug #88720: Adding pid option to resolve function of PersistedAliasMapper (Multi-site handling and Extbase enhancer slugs)Closed2019-07-11

Actions
Related to TYPO3 Core - Bug #91378: Slug isUniqueInTable is brokenClosedXavier Perseguers2020-05-13

Actions
Is duplicate of TYPO3 Core - Bug #91235: News Detail Page 404 after upgrade 9.5.16Closed2020-04-29

Actions
#1

Updated by Oliver Hader 9 months ago

  • Related to Bug #88720: Adding pid option to resolve function of PersistedAliasMapper (Multi-site handling and Extbase enhancer slugs) added
#2

Updated by Oliver Hader 9 months ago

  • Related to Bug #91235: News Detail Page 404 after upgrade 9.5.16 added
#3

Updated by Oliver Hader 9 months ago

  • Status changed from New to Needs Feedback

Looks like this was address in TYPO3 v9.5.17 with https://review.typo3.org/c/Packages/TYPO3.CMS/+/64455 - could you please give it a try and report back, thx!

#4

Updated by cosmoblonde GmbH 9 months ago

I experience the same problem with 9.5.17.
There are no changes in the Aspect classes from 16 to 17.
The related issues result in the same 404 error but were caused by identical slug values from different folders in different sites.
In my case the slugs are generated correctly and there exists only a single folder containing my records.

It sounds like comment https://forge.typo3.org/issues/88720#note-38 is describing the problem I have.

Disabling the PID check via a new setting might be the safest option in my opinion.

Thanks!
Ulrike

#5

Updated by Oliver Hader 9 months ago

  • Description updated (diff)
#6

Updated by Helmut Hummel 9 months ago

  • Related to deleted (Bug #91235: News Detail Page 404 after upgrade 9.5.16)
#7

Updated by Helmut Hummel 9 months ago

  • Is duplicate of Bug #91235: News Detail Page 404 after upgrade 9.5.16 added
#8

Updated by Helmut Hummel 9 months ago

This is basically a duplicate of #91235

Let me stress again, that I totally understand that having a bugfix release break your installation is troublesome.
Sorry for that.

Nevertheless that changes applied are a valid fix. We (and I in particular) underestimated how much the use case of having records in a different
site than where they are rendered is out in the wild.

Can you please adjust the PID check or add an additional configuration parameter to disable that check?

There actually is a configuration that is checked. That is the "eval" setting "uniqueInSite". If you change that to eval to "unique",
the behaviour is exactly like you'd expect. Slugs are enforced to be unique in the complete TYPO3 installation, enabling you to render them with URLs in any site.

Be aware though, that the currently released versions still have a bug related to uniqueness of slugs on save, that was addressed here: https://review.typo3.org/q/Ie7862b22a06996a9d7ca484a01d7a1859c8f7276
A release is pending for that.

#9

Updated by Oliver Hader 9 months ago

  • Related to Bug #91378: Slug isUniqueInTable is broken added
#10

Updated by Oliver Hader 9 months ago

  • Tags set to pending-close
#11

Updated by cosmoblonde GmbH 9 months ago

Hi Helmut,

I am sorry but I do not agree on this:

There actually is a configuration that is checked. That is the "eval" setting "uniqueInSite". If you change that to eval to "unique",
the behaviour is exactly like you'd expect. Slugs are enforced to be unique in the complete TYPO3 installation, enabling you to render them with URLs in any site.

My slugs are unique, as I only have a single folder containing all my records. The URLs are generated correctly but I am not allowed to access the page due to this function in SiteAccessorTrait:

    /**
     * Determines whether page is contained in current site
     * (resolved from current SiteLanguage).
     *
     * @param int $pageId
     * @return bool
     */
    protected function isPageIdContainedInSite(int $pageId): bool
    {
        try {
            $expectedSite = $this->getSiteMatcher()->matchByPageId($pageId);
            return $expectedSite->getRootPageId() === $this->site->getRootPageId();
        } catch (SiteNotFoundException $exception) {
            return false;
        }
    }

As far as I understand it, the pageId checked in that function is the records PID and not the detail page PID. If this assumption is correct, then a different eval setting for the slug field will not solve this issue.

I would appreciate if you could check my assumption.

Thank you!
Ulrike

#12

Updated by Helmut Hummel 9 months ago

Hi Ulrike!

cosmoblonde GmbH wrote:

My slugs are unique, as I only have a single folder containing all my records.

Yes, that's fine and I totally get, that it is annoying that you now need to take action.
However there are other users with other use cases and therefore different setups.

The URLs are generated correctly but I am not allowed to access the page due to this function in SiteAccessorTrait:

There are three angles to look at it.

  1. Saving a record / slug generation
  2. URL generation
  3. URL resolving

URL generation is the easiest one, so let's start here.
Generated URLs are based on the site they are generated for and use the slug stored in the database.

URL resolving is a bit trickier, but only a bit.
URLs are split into multiple parts and each part is resolved individually.
A configured PersistentAliasMapper recieves a slug and must resolve a single record UID as result.
For this to work, slugs stored in the database must be unique for the current site.
In other words: A single/distinct URL in a site must resolve to exactly one page exactly, one language and exactly one record.
How is it guaranteed that one part of the URL representing a record (the slug) is only representing one record?
It is done when generating the slug/ saving the record.

Which leads us to slug generation:
Due to how TYPO3 works in general, records are not free floating, but alwasy bound to a storage page.
This storage page has some location in the page tree.
When an editor now creates or edits a record, TYPO3 must ensure the slug is unique enough, so that
URLs (to repeat: URLs are always generated based on a site) are unique as well.

Now here comes the clue:
When saving a record, TYPO3 must know, in which site(s) the slug is going to be used to resolve exactly one record.
This is (currently) done like that:
  • When TCA eval setting for the slug field is set to "uniqueInSite", the site of the storage page is resolved and it is checked whether other records in the site of the storage page exist, which have the same slug
  • When TCA eval setting is "uniqueInPid", then only slugs in the same storage folder must be unique
  • When TCA eval setting is "unique", then slugs of this record type must be unique in the complete TYPO3 instance

This means:

If you have two different storage folders for e.g. news in two different sites, a news stored in site A can (is allowed to have) have the same slug as a news stored in site B, when TCA is set to "uniqeInSite".
For URL resolving this means, TYPO3 must ensure the correct news record, the one that belongs to the correct site, must be resolved.
And exactly this is what has been fixed.

You could now argue, that this should only happen, if you configure your persistent alias mapper accordingly (which is basically what ask for in this ticket).
This would mean however, that we would have two settings for the exact same thing. People with this use case, would need to configure both and need to configure both (TCA and routing config) to match.

It is true, that most of the above does not apply to your use case. From a technical and conceptual point of view, your use case is to have a global
record storage and having URLs to these records in one or more sites. The correct global configuration for that use case is to set the TCA to "unique"

As far as I understand it, the pageId checked in that function is the records PID and not the detail page PID. If this assumption is correct, then a different eval setting for the slug field will not solve this issue.

I would appreciate if you could check my assumption.

The check for the TCA setting is done here:
https://github.com/TYPO3/TYPO3.CMS/blob/cb0d4629d8c45539ee1d0fee25905a501532a0ea/typo3/sysext/core/Classes/Routing/Aspect/AspectTrait.php#L24-L30

The information whether the slug field is set to uniqueInSite is stored in a property here:
https://github.com/TYPO3/TYPO3.CMS/blob/cb0d4629d8c45539ee1d0fee25905a501532a0ea/typo3/sysext/core/Classes/Routing/Aspect/PersistedAliasMapper.php#L138

The filtering based on site you mention is only performed in the end, when TCA is set to uniqueInSite
https://github.com/TYPO3/TYPO3.CMS/blob/cb0d4629d8c45539ee1d0fee25905a501532a0ea/typo3/sysext/core/Classes/Routing/Aspect/PersistedAliasMapper.php#L240

This means, you need to change TCA to "unique" and your use case is covered with a simple configuration change, just like you desired to have.

(note though that you may still be affected by a bug in the currently released versions until this fix https://review.typo3.org/q/Ie7862b22a06996a9d7ca484a01d7a1859c8f7276 is released)

Please check whether changing TCA indeed works in your instance (like I would expect and have verified in test setups).

Thanks

#13

Updated by cosmoblonde GmbH 9 months ago

Hi Helmut,

thanks for the detailed explanation. I did not realize that the eval=unique setting (which is never mentioned in any documentation) is also checked when resolving an URL.
The change in the TCA did indeed fix the issue!

Thank you!
Ulrike

#14

Updated by Oliver Hader 9 months ago

  • Status changed from Needs Feedback to Closed

cosmoblonde GmbH wrote:

The change in the TCA did indeed fix the issue!

Thanks for reporting back. I'm going to close this issue - feel free to reopen it, in case there is additional input that has not been mentioned.

#15

Updated by Helmut Hummel 9 months ago

cosmoblonde GmbH wrote:

thanks for the detailed explanation. I did not realize that the eval=unique setting (which is never mentioned in any documentation)

This has been fixed meanwhile:

https://docs.typo3.org/m/typo3/reference-tca/master/en-us/ColumnsConfig/Type/Slug.html#eval

The change in the TCA did indeed fix the issue!

Thanks. To be sure to not run into another issue, please make sure to apply this change in case you are on latest released version:
https://review.typo3.org/q/Ie7862b22a06996a9d7ca484a01d7a1859c8f7276

A new release is planned soon as well.

Also available in: Atom PDF