1.x ContentCultureSelector doesn't work in multi tenant scenario with url prefix

[orchardbot]

@netwavebe created: https://orchard.codeplex.com/workitem/21250

1.x branch: ContentCultureSelector (in module Orchard.Localization) has a problem when used in a multi tenant environment if the tenant has a URL prefix set.

After stripping ApplicationPath from the request path, the URL prefix should also be stripped before calling "var content = GetByPath(requestUrl);".

[orchardbot]

@jtkech commented:

You're right, and without multi tenant it's the same if you have a virtual directory. It's one of the issues I've pointed out, see #21200 and #21243

Here, the alias extraction should always use an AbsolutePath, and remove the Request.ApplicationPath from the beginning of this AbsolutePath... With "Content Picker" enabled, I had another issue by editing an html element in the Layout editor. Here, in case of a post request, the fix was to check if the Request.UrlReferrer is null. For these 2 points, see #21200 for a proposed fix

Best

[orchardbot]

@netwavebe commented:

ApplicationPath is being stripped now. Check the 1.x branch.

But, just like you, I also had to test Request.UrlReferrer not being null to be able to edit an html element in the layout editor. Totally forgot about this one. Is there an issue I can upvote?

I also noticted it is called very often. But it's not a performance issue for me at this time.

[orchardbot]

@jtkech commented:

You're right, the ApplicationPath is used now, I've checked the last 1.9-int branch

But just before we need at least to replace

path = context.Request.Path;

With

path = context.Request.Url.AbsolutePath;

I didn't try this version, but, in some situations, I think we also need to trim "/" at the end to extract the alias path, and maybe it's better to use "StringComparison.OrdinalIgnoreCase" to see if the path starts with ApplicationPath... See in #21200 the fix I propose for this point

For upvoting, there are #21243 and #21200 that talk about this but it's just one point among others ones... On my side I just upvoted this issue

Best

Best

[orchardbot]

@jtkech commented:

Update:

Just re-tried with the last version, it's ok for the ApplicationPath, and Request.Path is the same as Request.Url.AbsolutePath, sorry. So, it remains to check the Request.UrlReferrer and solve the frequent calls issue #21243

Best

[orchardbot]

@sebastienros commented:

@jtkech, should we close this one then ? The one you are mentioning is also fixed.

[orchardbot]

@jtkech commented:

You're right, it's ok for me

[orchardbot]

@netwavebe commented:

This issue is fixed!