[jira] [Created] (SLING-10466) Ability of scoping sling:vanityPath per content path

["Henry Kuijpers (Jira)" <ji...@apache.org>]

Henry Kuijpers created SLING-10466:
--------------------------------------

             Summary: Ability of scoping sling:vanityPath per content path
                 Key: SLING-10466
                 URL: https://issues.apache.org/jira/browse/SLING-10466
             Project: Sling
          Issue Type: Improvement
          Components: ResourceResolver
    Affects Versions: Resource Resolver 1.7.8
            Reporter: Henry Kuijpers


The sling mappings provide the possibility of creating a multi-tenant setup. Multiple websites can be hosted, by providing Sling mappings that point to their specific content paths. These mappings consist of domains. I.e.:

  *   https://my-website-a.com -> /content/my-website-a
  *   https://my-website-b.com -> /content/my-website-b

There is, however, an issue with this setup, when using sling:vanityPath.

Let’s say, we have the following structure:
/content/my-website-a/info/openinghours@sling:vanityPath=’/openinghours’
/content/my-website-b/test@sling:vanityPath=’/test’

Now:

When requesting https://my-website-a.com/openinghours , we see the content of /content/my-website-a/info/openinghours (sling:vanityPath) – Correct

When requesting https://my-website-b.com/openinghours , we see the content of /content/my-website-b/info/openinghours – Incorrect! This content does not belong to this website!

The /test vanity is also available within both websites.

There seems to be support in Apache Sling for sling:vanityPath properties containing a full URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/4406b8fed0fedb48202fc6472fb552c36aa06e35/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L1285 This could be used to make the above work.  However, that would require us to store the protocol, domain & portnumber inside the sling:vanityPath property. That does not feel right.

There is another option: We could try to use custom code to put the domains in front of sling:vanityPath property values, by using a ResourceDecorator. However, the ResourceDecorator in our custom bundle would not be started yet, when Sling is starting up and doing the inventory, because our bundle is dependent on the resourceresolver-bundle.

Also, another issue is that, when the mappings update, we would need to let Sling re-scan everything (because our ResourceDecorator now has put the wrong domain in front of all property values).

This basically leaves us without any good “hook” into this entire process.

If the sling:vanityPath property value contains a path (not a URL), https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/4406b8fed0fedb48202fc6472fb552c36aa06e35/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L1291 , the ANY_SCHEME_HOST constant is used, which has a value of “[^/]+/[^/]+” which basically means that any scheme and any host matches. Given the usecase I just described, it means that no matter where the sling:vanityPath properties are stored, as long as they match the request *path* only, they match. Then, the first one that is encountered (through the Iterator provided by getResolveMapsIterator) – Potentially the wrong one!

When handling sling:vanityPath properties, there is not really any context of domains, Sling mappings, … Purely a vanity path.

I think it could be possible to take the map entries into account, when handling the vanity paths. This should mean that the ANY_SCHEME_HOST-constant would not be used as part of the regex, but instead, we determine the host at a later part, by taking into account the Sling mappings.

This would make the following cases possible:

  1.  Scope sling:vanityPath defined in a content path covered by a mapping, to only that mapping, causing them to not be able to be requested by other domains;
  2.  When having found multiple content paths defining the same sling:vanityPath, be able to actually select the right one (not tackling the issue where 2 or more of the same vanity paths are defined under the same content path);
  3.  Add a new Sling mapping (or remove / update an existing one) and the sling:vanityPath scoping work right away.

So far, I’ve been experimenting a bit with the above and it seems most of it is possible already, just that MapEntry (which is where the ANY_SCHEME_HOST + vanity path value ends up as a regex) doesn’t have any knowledge of the Sling mappings. I was thinking of making a wrapper class, to store the vanity path without the scheme/host/port and allow it to dynamically select the right one based on the request coming in.

I suppose it’s a good idea to be able to toggle this functionality, so that we don’t interfere with existing setups. And also, if a content path defines a sling:vanityPath that is not covered by a Sling Mapping – Should that sling:vanityPath be global then? Or not work at all? (I think it should be global, then.)

Does anyone have any thoughts about this? 😊

If we’re able to decide how we want to approach this, I can put in some effort to make the changes.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)