CMS modules and authorization configuration problems

Erik Täck

Vote:

So I have a simple addon module that adds a button to the global command toolbar, the button itself just calls an API, its not that important for this question.

Now, I want to restrict this button to only appear for certain users, and there is the concept of authorization policies in module.config described here, perfect!: https://docs.developers.optimizely.com/content-management-system/docs/configuring-shell-modules

However, in the link above you can see how to add authorizationPolicy and also a clientAuthorizationPolicy, these values does not seem to affect anything at all when applied. I can still access my commands with a user that do not have the access rights defined in the policy. I have verified the policy itself works by applying it to a controller.

I am guessing I may have to do something in my client module to check this access and not load the commands if so, or perhaps I need to do somethign else entirely to make the module not be loaded for a user not authorized by the set authroizationpolicy?

Also, what is the difference between authorizationPolicy and clientAuthorizationPolicy?

Anyone with any idea what I am missing?

#317035

Edited, Feb 12, 2024 9:07

Robert Svallin

Vote:

For a protected module, that is a module located in the /modules/_protected/ folder, setting the clientAuthorizationPolicy will limit to whom the resources are served. You could allow to serve js files to the client but disallow requests to be handled by the server. Perhaps you would want a feature to be visible but not interactive if you dont have the right permissions.

#317041

Feb 12, 2024 16:51

Erik Täck - Feb 12, 2024 17:10

Regarding:
> Perhaps you would want a feature to be visible but not interactive if you dont have the right permissions.
How would you make a shell client script non-interactive by only disallow requests? It sounds like that alone would simply give an error when the client scripts try to access the server? Is there any way in the dojo scripts to check if the current user have server access?

Erik Täck

Vote:

Ah yes! Thats exactly what I want, now anyone with any idea why it doesnt work? regardless of what policy I set in any of the two properties, the module serves all client files to the active user.
I have verified that the shellmodule instance when the site is up have the correct policy set in its manifest property, it just doesnt really seem to affect anything.

I could of course just add my own auth policy to the path of where the files are served from, but I suspect it will just cause a number of 401 errors for the visitor instead of actually not serving the files in the first place.

#317042

Feb 12, 2024 17:08

Robert Svallin

Vote:

Where is your module located? Is the module.config in the root of the web application? In the modules folder or the modules/_protected folder?

#317045

Feb 12, 2024 17:29

Erik Täck

Vote:

Its a protected module so the latter. I also checked during runtime that its located in the EPiServer.Shell.Modules.ProtectedModuleOptions.Items (it is), because my first suspicion was also that it was considered public.

#317046

Feb 12, 2024 17:53

Robert Svallin

Vote:

Any chance you would consider publishing a simplified sample that I can test on an basic alloy project?

#317082

Feb 13, 2024 8:10

Erik Täck

Vote:

I would, but I dont have the time right now, we're in the middle of a CMS11-12 upgrade. For the time being its not critical for the project, but its very likely I will revist this later and will then be able to upload something after I strip some client-specific stuff.

The module is using a small library to package modules inside assemblies rather then as files on disk, which could also be part of the problem. But other then this issue, modules are working as they are supposed to.

With the above being said, would you know where the logic where Epi is wiring up the authorizationpolicies is located (assembly/class)? I might be able to figure something out by reflecting that.

#317085

Feb 13, 2024 8:44