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?
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.
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.
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?
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.
Any chance you would consider publishing a simplified sample that I can test on an basic alloy project?
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.