Avoid redirect to culture bound domain for site

Vote:
 

Hi there!

Our customer currently use only one domain for all languages, and would now like to split these to one domain per language.

They do also have an internal URL (internal-url.domain.local/lang) only accessible through their local network, which enables certain features for sales representatives.
The issue here is that when binding a culture to a specific domain, all URLs for this languages is resolved using that host definition.
This results in all links on the internal site taking the user to the public domain.

Is there any way of replacing the default host definition resolver or similar to make sure that users on the internal URL will stay on the internal URL?

The last resort as I see it, is throwing out this special handling using URLs and use virtual roles or similar instead.
That option builds time and costs that we would like to avoid if we can.

Best,
//Patrick Fogwall

#196651
Sep 06, 2018 9:51
Vote:
 

The component that does the host resolving is EPiServer.Web.Routing.Internal.VirtualPathHostResolver. As you see is it placed in an internal namespace so it is not inteded to be extended and hence are any extensions to it nothing that we officially support.

With that said one option is to Intercept that type and then in your interceptor for the method GetVirtualPathHost you can check if the current request is on the internal domain then return the HostDefinition for that domain else you just delegate the call to the default implementation of VirtualPathHostResolver.

#196678
Sep 07, 2018 10:28
Vote:
 

Alright, thanks Johan!

I've been looking into exactly that path, but as it is internal I've avoided it.
Will try it out now though.

Any plans on making this an official extension point?

Edit:

Hmm, it doesn't look like the VirtualPathHostResolver is instantiated via the container.
The instance passed to DefaultContentRoute looks to be created using the constructor directly (using Episerver 10.10.4).

Any ideas?

#196681
Edited, Sep 07, 2018 14:32
Vote:
 

Not really answering your question, but some thoughts that might take you to a solution for your problem:

#196780
Sep 11, 2018 15:12
Vote:
 

Thanks for your input!

For our case the additional language would not be good enough, there are too many languages and content items (both CMS and Commerce).

I looked into some URL rewriting before diving deep into possible Episerver workarounds, but left it after some headaches.
The internal features are spread around the normal content structure and is not grouped under e.g. /internalpages, so inbound rewriting could prove hard.
Outbound rewriting could possibly work. There is the issue of some URL:s being output as data-tags for use in scripts and similar which could be problematic. 
We also have a multisite solution, each having their own set of language specific domains and I think it would be quite a lot of configuration to maintain.

I have an upcoming discussion with the customer regarding alternative solutions to the internal domains.
Hopefully we can find some other approach to this without wrecking their routines. 
It would clearly be preferable maintaining "Episerver standard" and not relying on these workarounds, especially in the long run.

#196805
Sep 12, 2018 8:01
Vote:
 

After talking with the customer, the decision was taken to solve it using outbound rewrites.
There is maintanence involved and maybe some gotchas but the customer is aware of it.

The following rule seems to do the trick and we have quite a few of these now, one per culture specific domain per site.

<rewrite>
  <outboundRules>
    <rule name="IntranetEN" preCondition="IsHtml" patternSyntax="ECMAScript">
    <match filterByTags="A" pattern="(?:http(?:s)?://)?www\.external-hostname\.com(.*)" />
    <action type="Rewrite" value="http://internal-hostname{C:1}/en{R:1}" />
    <conditions>
      <add input="{HTTP_HOST}" pattern="internal-hostname(\.internal-domain)?" />
    </conditions>
    </rule>
    <preConditions>
      <preCondition name="IsHtml">
        <add input="{RESPONSE_CONTENT_TYPE}" pattern="text/html" />
      </preCondition>
    </preConditions>
  </outboundRules>
</rewrite>

I still would wish I could have solved this in Episerver though. :)

Thanks for your input Erik and Johan!

#196887
Edited, Sep 14, 2018 13:28
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.