[MGNLETK-126] Multisite behavior: Site definition detection in ETKSiteManager does not cover all "corner" cases Created: 18/Mar/14  Updated: 04/Jul/14  Resolved: 03/Jul/14

Status: Closed
Project: Extended Templating Kit (closed)
Component/s: None
Affects Version/s: 2.0.17
Fix Version/s: 2.0.21

Type: Bug Priority: Major
Reporter: Christian Ringele Assignee: Philip Mundt
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File SiteDefinition-NamedDifferentThanTheMapping-Drawback.jpg     JPEG File SiteDefinition-NamedDifferentThanTheMapping-Result.jpg     JPEG File SiteDefinition-NamedDifferentThanTheMapping.jpg     XML File config.modules.extended-templating-kit.config.rules.xml     XML File config.modules.extended-templating-kit.config.sites.a.xml     XML File config.modules.extended-templating-kit.config.sites.b.xml     XML File config.modules.extended-templating-kit.config.sites.workaround-a.xml     XML File config.modules.extended-templating-kit.config.sites.workaround-b.xml     XML File website.a.xml     XML File website.b.xml     XML File website.c.xml    
Issue Links:
Cloners
is cloned by MULTISITE-18 Multisite behavior: Site definition d... Closed
causality
Template:
Acceptance criteria:
Empty
Release notes required:
Yes
Date of First Response:

 Description   

The same behavior also counts for the multi site module of Magnolia 5.

Situation (from SUPPORT-3270):
Two sites & two site definitions, here in this ticket named site "a" and site "b" with site definition name "a" & "b".
Both have a domain mapping:

  • a -> www.test1.ch
  • b -> www.test2.ch

Use case:
Site /a needs a sub page with the same name as site b: /a/b
So this uri "www.test1.ch/b" should render the page "/a/b"

The problem:
The system will always serve the site b (node /b) instead of /a/b.
So it does a cross site access instead of rendering the sub page.

Analysis:
1. First it seems the system serves the site b because the site definition b maps to the site b. But it seems that the system always uses the site definition name if it matches and not even its mapping. One can change the mapping of site definition b pointing to site c: www.test1.ch/b will now serve site c!

2. As the system can not access at this state JCR to determine the site definitions it can only operate on on the site definition configurations them selves. Therefore the system detect a site definition which seems to serve this site (b site is assumed) and can not check if a actual sub page exists.

Proof & workaround:
Rename the site definition from b to "bbb" but leave it mapped to site /b. (and remove the two workaround site definitions)
Now www.test1.ch/b really serves the page /a/b.

Drawback of workaround:
Accessing the site b not vie its mapped domain internal links use the site definition's name and not its mapping value. The link & uri to the page /b/d is then "/bbb/d" which leads to the wrong assumption (and URL) that the root node is names bbb.

Wrong behavior:
1. One could argue that this behavior is correct, when there is no domain mapping in place. But when a domain mapping is detected, a request domain/page should always stay in its scope and not do a cross site access. If the domain/page does not exist, a 404 is correct out of my view, and not a cross site access.

2. Not the site definition's name should be used for the link creation (not resulting in "/bbb/d" paths) but its inner value of the mapped handle.
If you have more than one site definition mapped to the same site, one can't anyhow name them both identical to the site's root node. So this effect will show in at least one of the two used site definitions.

Reproduce & test:
Just import the bootstrap files I attached, and change the hosts file to point the two domains to local host.



 Comments   
Comment by Tobias Hitzfeld [ 21/Mar/14 ]

Hallo

Just a few additional points from customer side (sorry for my lack of technical know how and my bad english in advance; just missing german documentation and support).

business needs:

  1. We need cross-site configuration to prevent public from access of websites and content which is activated, but not live yet. We build new websites, migrate content and show responsibles of that website how it will look like on the public nodes - by using a special cross site configuration which is allowed to access all sites. The IP-Adresses which are allowed to access this domain are filtered.
  2. We need informations (logfiles, statistics, etc) which include the domain of a website (I recognized additionally that I can't see the domain in logfiles - localhost_access_log.yyyy-mm-dd.txt)
  3. Local Search engine must be up to date during activation of content (also over all sites) but it is not allowed to deliver search results of websites which aren't allready live.
  4. crawlers of Search engines must be prevented of crawling content of sites which aren't really live (due to acceptance of migration tasks all content must be activated - but DNS-Entries of the correct sitename leads still to old environment (in our case CMS Lifelink) - it shouldn't be possible for spiders to get content across other sites.
  5. Domain name and path must be separated due to redirects & forwards - we want to be able to redirect & forward also variable paths to another site (including values)
  6. It must be possible that a path of a website could include a string which is named like the domain - its under control of redactors how they name paths - so it must be possible that there is no dependence between domain and path

I think it will be essential at crossSite configurations that during all handling (logging, filter chain) the domain mus be added and recognized separately from the path. Even top level path (in our case the sitename) isn't included in these logfiles but paths are logged.

Regards,
Tobias

Comment by Jaroslav Simak [ 29/May/14 ]

Commit:
https://git.magnolia-cms.com/gitweb/?p=enterprise/extended-templating-kit.git;a=commit;h=6ed875dca2e7c7b8660201c4283eeffd2928e887

Comment by Philip Mundt [ 02/Jul/14 ]

Rules should be made configurable, so any "special case" can be individually solved.

Comment by Philip Mundt [ 02/Jul/14 ]
  • make rules configurable
  • extract protected inner classes
  • deprecate old inner classes (to maintain binary compatibility)
  • add default NullRequestMatcher for content2bean mechanism's default init
  • add bootstrap for old rules configuration
Comment by Philip Mundt [ 02/Jul/14 ]

Attaching rules configuration (config.modules.extended-templating-kit.config.rules.xml) that solves the above case. This config is not by default added to the modules configuration!

Comment by Roman Kovařík [ 02/Jul/14 ]
  1. Update task to bootstrap default rules is missing.
  2. Would it be possible to implement some converter to prevent code duplication in info.magnolia.module.extendedtemplatingkit.sites.ETKSiteManager.getRules()/getDefaultRules()?
Comment by Philip Mundt [ 03/Jul/14 ]
  1. Add MVH delta for new rules configuration
  2. Change inhertiance to prevent code duplication
Comment by Roman Kovařík [ 03/Jul/14 ]

To test:

  1. Binary compatibility of inner classes.
  2. Fallback to default rules if no rules are defined.
  3. Fix for the issue mentioned in this ticket config.modules.extended-templating-kit.config.rules.xml.
Comment by Roman Kovařík [ 03/Jul/14 ]

Could you remove info.magnolia.module.extendedtemplatingkit.setup.ETKModuleVersionHandlerTest.tearDown() when integrating? (it's done in info.magnolia.test.MgnlTestCase.tearDown() already).
And maybe add given/when/then to the test when you will be on it?

Generated at Mon Feb 12 01:48:43 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.