You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Kuijpers, Henry" <He...@amplexor.com> on 2021/06/07 17:19:07 UTC
Ability of scoping sling:vanityPath per content path
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!
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.
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.
With kind regards,
Henry Kuijpers
This email message is confidential and for the sole use of the intended recipient(s). For more information on our email security procedures and how we protect your data, check our www.amplexor.com/privacy<https://www.amplexor.com/en/privacy.html>. | Cet e-mail est confidentiel et pour l'usage exclusif du (des) destinataire(s) prévu(s). Pour plus d'informations sur nos procédures de sécurité relatives aux e-mails et à la manière dont nous protégeons vos données, veuillez consulter notre www.amplexor.com/politique-confidentialite<https://www.amplexor.com/fr/politique-de-confidentialite.html>.
Re: Ability of scoping sling:vanityPath per content path
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Henry,
agreed, yes makes sense to not let authors fiddle with it.
I think it would be good if we don't need extension points and can just
go via configuration.
Good idea to come up with some proposal for how to do the config
Regards
Carsten
Am 08.06.2021 um 17:14 schrieb Kuijpers, Henry:
> Hi Carsten,
>
> While I like your idea, the same issues will arise if we put that “map:/” (or similar) prefix there with a ResourceDecorator.
>
> And I don’t think letting the content author add that prefix is very intuitive (almost feels like programming/configuring).
>
> I was thinking more of an approach that involved updating the resource-resolver module with some extension point(s) and/or the functionality itself, that we can then use to facilitate these kinds of configurations.
>
> I think question number one is: Where and how do we want to configure this kind of scoping? I’ll try to draft a few proposals, maybe we can use those to shoot at them and come to the right solution.
>
> With kind regards,
> Henry Kuijpers
>
>
> From: Carsten Ziegeler <cz...@apache.org>
> Date: Tuesday, 8 June 2021 at 09:05
> To: dev@sling.apache.org <de...@sling.apache.org>
> Subject: Re: Ability of scoping sling:vanityPath per content path
> Hi,
>
> yes, I think supporting such scoping makes sense.
>
> In general, we must preserve existing functionality - how about opting
> in to the scoping by using a special prefix as part of the value for the
> vanityPath like sling:vanityPath=map:/openinghours?
>
> (map: might not be the best prefix, but just demonstrating the idea)
>
> Regards
> Carsten
>
>
> Am 07.06.2021 um 19:19 schrieb Kuijpers, Henry:
>> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy-website-a.com%2F&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554768753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CUi3UztfTeuFgdx7%2B7IeO8nRpb588%2FjYDS2o3j2xA14%3D&reserved=0 -> /content/my-website-a
>> * https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy-website-b.com%2F&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XCWB%2FtAgJgcrZvIzUyRbiqw1zYrhuJ%2Fk2h1I2zDQ5Eo%3D&reserved=0 -> /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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy-website-a.com%2Fopeninghours&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9vDVIDT4TxomOhDfEqQAdCIBge64G%2BSrsZaH9q6nngU%3D&reserved=0 , we see the content of /content/my-website-a/info/openinghours (sling:vanityPath) – Correct
>>
>> When requesting https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy-website-b.com%2Fopeninghours&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BGio9FKt8f5vzw9mbCnvak58notoTM0X7npIQcrBH7w%3D&reserved=0 , we see the content of /content/my-website-b/info/openinghours – Incorrect! This content does not belong to this website!
>>
>> There seems to be support in Apache Sling for sling:vanityPath properties containing a full URL: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fsling-org-apache-sling-resourceresolver%2Fblob%2F4406b8fed0fedb48202fc6472fb552c36aa06e35%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fsling%2Fresourceresolver%2Fimpl%2Fmapping%2FMapEntries.java%23L1285&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oe4rqGXdcLvvHr8o1zOiGsV4dc6q70dOWlVXa%2BhKyLs%3D&reserved=0 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.
>>
>> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fsling-org-apache-sling-resourceresolver%2Fblob%2F4406b8fed0fedb48202fc6472fb552c36aa06e35%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fsling%2Fresourceresolver%2Fimpl%2Fmapping%2FMapEntries.java%23L1291&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Kg0SuZWCWXC8NzRz0HpbQ0clw7DzxFZYgSJElvsE7qM%3D&reserved=0 , 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.
>>
>> With kind regards,
>> Henry Kuijpers
>>
>> This email message is confidential and for the sole use of the intended recipient(s). For more information on our email security procedures and how we protect your data, check our https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.amplexor.com%2Fprivacy&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9T7o3PxDWo1%2Bqi%2BFszas4TQ9Fy9ESWaQwka6LRpKgUw%3D&reserved=0<https://www.amplexor.com/en/privacy.html<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.amplexor.com%2Fprivacy&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9T7o3PxDWo1%2Bqi%2BFszas4TQ9Fy9ESWaQwka6LRpKgUw%3D&reserved=0%3chttps://www.amplexor.com/en/privacy.html>>. | Cet e-mail est confidentiel et pour l'usage exclusif du (des) destinataire(s) prévu(s). Pour plus d'informations sur nos procédures de sécurité relatives aux e-mails et à la manière dont nous protégeons vos données, veuillez consulter notre https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.amplexor.com%2Fpolitique-confidentialite&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s%2FEj1v7b%2BgtJg11C1IJ%2FsTzolsUwYSGhExfgiaA1mqY%3D&reserved=0<https://www.amplexor.com/fr/politique-de-confidentialite.html<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.amplexor.com%2Fpolitique-confidentialite&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s%2FEj1v7b%2BgtJg11C1IJ%2FsTzolsUwYSGhExfgiaA1mqY%3D&reserved=0%3chttps://www.amplexor.com/fr/politique-de-confidentialite.html>>.
>>
>
> --
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
> This email message is confidential and for the sole use of the intended recipient(s). For more information on our email security procedures and how we protect your data, check our www.amplexor.com/privacy<https://www.amplexor.com/en/privacy.html>. | Cet e-mail est confidentiel et pour l'usage exclusif du (des) destinataire(s) prévu(s). Pour plus d'informations sur nos procédures de sécurité relatives aux e-mails et à la manière dont nous protégeons vos données, veuillez consulter notre www.amplexor.com/politique-confidentialite<https://www.amplexor.com/fr/politique-de-confidentialite.html>.
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Ability of scoping sling:vanityPath per content path
Posted by "Kuijpers, Henry" <He...@amplexor.com>.
Hi Carsten,
While I like your idea, the same issues will arise if we put that “map:/” (or similar) prefix there with a ResourceDecorator.
And I don’t think letting the content author add that prefix is very intuitive (almost feels like programming/configuring).
I was thinking more of an approach that involved updating the resource-resolver module with some extension point(s) and/or the functionality itself, that we can then use to facilitate these kinds of configurations.
I think question number one is: Where and how do we want to configure this kind of scoping? I’ll try to draft a few proposals, maybe we can use those to shoot at them and come to the right solution.
With kind regards,
Henry Kuijpers
From: Carsten Ziegeler <cz...@apache.org>
Date: Tuesday, 8 June 2021 at 09:05
To: dev@sling.apache.org <de...@sling.apache.org>
Subject: Re: Ability of scoping sling:vanityPath per content path
Hi,
yes, I think supporting such scoping makes sense.
In general, we must preserve existing functionality - how about opting
in to the scoping by using a special prefix as part of the value for the
vanityPath like sling:vanityPath=map:/openinghours?
(map: might not be the best prefix, but just demonstrating the idea)
Regards
Carsten
Am 07.06.2021 um 19:19 schrieb Kuijpers, Henry:
> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy-website-a.com%2F&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554768753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CUi3UztfTeuFgdx7%2B7IeO8nRpb588%2FjYDS2o3j2xA14%3D&reserved=0 -> /content/my-website-a
> * https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy-website-b.com%2F&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XCWB%2FtAgJgcrZvIzUyRbiqw1zYrhuJ%2Fk2h1I2zDQ5Eo%3D&reserved=0 -> /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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy-website-a.com%2Fopeninghours&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9vDVIDT4TxomOhDfEqQAdCIBge64G%2BSrsZaH9q6nngU%3D&reserved=0 , we see the content of /content/my-website-a/info/openinghours (sling:vanityPath) – Correct
>
> When requesting https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy-website-b.com%2Fopeninghours&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BGio9FKt8f5vzw9mbCnvak58notoTM0X7npIQcrBH7w%3D&reserved=0 , we see the content of /content/my-website-b/info/openinghours – Incorrect! This content does not belong to this website!
>
> There seems to be support in Apache Sling for sling:vanityPath properties containing a full URL: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fsling-org-apache-sling-resourceresolver%2Fblob%2F4406b8fed0fedb48202fc6472fb552c36aa06e35%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fsling%2Fresourceresolver%2Fimpl%2Fmapping%2FMapEntries.java%23L1285&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oe4rqGXdcLvvHr8o1zOiGsV4dc6q70dOWlVXa%2BhKyLs%3D&reserved=0 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.
>
> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fsling-org-apache-sling-resourceresolver%2Fblob%2F4406b8fed0fedb48202fc6472fb552c36aa06e35%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fsling%2Fresourceresolver%2Fimpl%2Fmapping%2FMapEntries.java%23L1291&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Kg0SuZWCWXC8NzRz0HpbQ0clw7DzxFZYgSJElvsE7qM%3D&reserved=0 , 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.
>
> With kind regards,
> Henry Kuijpers
>
> This email message is confidential and for the sole use of the intended recipient(s). For more information on our email security procedures and how we protect your data, check our https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.amplexor.com%2Fprivacy&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9T7o3PxDWo1%2Bqi%2BFszas4TQ9Fy9ESWaQwka6LRpKgUw%3D&reserved=0<https://www.amplexor.com/en/privacy.html<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.amplexor.com%2Fprivacy&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9T7o3PxDWo1%2Bqi%2BFszas4TQ9Fy9ESWaQwka6LRpKgUw%3D&reserved=0%3chttps://www.amplexor.com/en/privacy.html>>. | Cet e-mail est confidentiel et pour l'usage exclusif du (des) destinataire(s) prévu(s). Pour plus d'informations sur nos procédures de sécurité relatives aux e-mails et à la manière dont nous protégeons vos données, veuillez consulter notre https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.amplexor.com%2Fpolitique-confidentialite&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s%2FEj1v7b%2BgtJg11C1IJ%2FsTzolsUwYSGhExfgiaA1mqY%3D&reserved=0<https://www.amplexor.com/fr/politique-de-confidentialite.html<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.amplexor.com%2Fpolitique-confidentialite&data=04%7C01%7C%7C367f6057a9cb4b6e8d2108d92a4bd92a%7C2f436130bd914cfbb216a9127020e559%7C0%7C0%7C637587327554778747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s%2FEj1v7b%2BgtJg11C1IJ%2FsTzolsUwYSGhExfgiaA1mqY%3D&reserved=0%3chttps://www.amplexor.com/fr/politique-de-confidentialite.html>>.
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
This email message is confidential and for the sole use of the intended recipient(s). For more information on our email security procedures and how we protect your data, check our www.amplexor.com/privacy<https://www.amplexor.com/en/privacy.html>. | Cet e-mail est confidentiel et pour l'usage exclusif du (des) destinataire(s) prévu(s). Pour plus d'informations sur nos procédures de sécurité relatives aux e-mails et à la manière dont nous protégeons vos données, veuillez consulter notre www.amplexor.com/politique-confidentialite<https://www.amplexor.com/fr/politique-de-confidentialite.html>.
Re: Ability of scoping sling:vanityPath per content path
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
yes, I think supporting such scoping makes sense.
In general, we must preserve existing functionality - how about opting
in to the scoping by using a special prefix as part of the value for the
vanityPath like sling:vanityPath=map:/openinghours?
(map: might not be the best prefix, but just demonstrating the idea)
Regards
Carsten
Am 07.06.2021 um 19:19 schrieb Kuijpers, Henry:
> 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!
>
> 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.
>
> 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.
>
> With kind regards,
> Henry Kuijpers
>
> This email message is confidential and for the sole use of the intended recipient(s). For more information on our email security procedures and how we protect your data, check our www.amplexor.com/privacy<https://www.amplexor.com/en/privacy.html>. | Cet e-mail est confidentiel et pour l'usage exclusif du (des) destinataire(s) prévu(s). Pour plus d'informations sur nos procédures de sécurité relatives aux e-mails et à la manière dont nous protégeons vos données, veuillez consulter notre www.amplexor.com/politique-confidentialite<https://www.amplexor.com/fr/politique-de-confidentialite.html>.
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org