Try our conversational search powered by Generative AI!

How to restrict access to specific localizations/languages?

swc
swc
Vote:
 

Performing our first localization, and have a few questions:

On our site, a given localization is only available to users who meet a specific criterion (they are in the market where that localization applies).  e.g. Not everyone who requests /sv/ can see that branch, for instance, only users who are affiliated with Sweden.  I am trying to work out the best means of implementing this.

The most seamless implementation I can think of would be to add an action filter that checks the incoming request as it starts, and sets the language to be used for the request up front.  The problem I have is that I can't seem to find a hook where I can set the language for the request without it later getting overwritten.  e.g. if the user requests /sv/ and I add an ActionFilter OnActionExecuting that sets the language, by the time it reaches the controller, EpiServer seems to have reset the language to /sv/ again.  Is there a way to do this?

As an alternative, I would like to check when a user requests /sv/some-piece-of-content/ and if they are allowed access to that localization, and if not, then redirect them to the master language branch (en) for that piece of content, if it exists.  What is the best hook for implementing this type of functionality?  Current thinking is a custom AuthorizeContentAttribute.  Any downfalls here?

Any other options you'd suggest instead?

Thanks!   

#115423
Jan 14, 2015 21:13
Vote:
 

Hi

to answer partly to your first idea of changing the language the way you describe doesn't work because the url /sv/some-page/ contains the language for the EPiServer default routing (so what happens is that you change the thread language but the routing picks up the sv fragment and uses that as the language and it is also routing to the swedish content). So to make it work you should be changing the default routing and I don't think you want to do that in this case.

If the requirement is not to allow an anonymous user to access some content if they don't meet your rules. I would simply build the checking as early as possible for example in a authorizationfilter if you have all the episerver information there you need or in a actionfilter (onactionexecuting) where you definetly have already all the episerver routed data.

(I suppose this functionality requirement comes from customers marketing team perhaps? ;-D but anyways what about search bots? Basically if this gets implemented the content is never going to be indexed and never to be found by customers using search services or if there is a rule that checks for crawlers and that way get indexed to search services then it creates the case where someone tries to access the page from search results they get redirected somewhere else which might not be a good user experience)

#115430
Jan 15, 2015 6:57
swc
Vote:
 

To answer partly to your first idea of changing the language the way you describe doesn't work because the url /sv/some-page/ contains the language for the EPiServer default routing (so what happens is that you change the thread language but the routing picks up the sv fragment and uses that as the language and it is also routing to the swedish content). So to make it work you should be changing the default routing and I don't think you want to do that in this case.

Right, this is what I assumed was happening.  I was hoping maybe there was a hook that could be used after the language routing had initially run, but it seems like there isn't.

Sounds like the the authorization attribute is acceptable.

Re: SEO, this site is internal to the company, so external search is not a consideration.  Internal search via EpiServer Find is, but I'm pretty sure we can work something out there.

Thanks!

#115664
Jan 15, 2015 16:02
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.