Context Access - getting ACLs right

I'm trying to get permissions sorted out for a few different contexts, and so far I can't seem to make it work.

I have a context, "assets", that contains a lot of my site's css and js. For various reasons I want to lock all other mgr users with authority less than 0 out of the assets context, but for frontend users MODx still needs to access the context to get the css/js. I can only seem to do one, and not the other. EG, if I use the following ACL:
Context: assets,
Min Role: 9999,
Policy: Administrator,
only the Super User can see the assets context in the backend. But the css becomes hidden in the front end too.

How can I have both? [ed. note: moniarde last edited this post 14 years, 9 months ago.]

That's because any context other than mgr is essentially a front-end context. Anything you protect will be protected in the front end.

I'd suggest getting rid of that context and putting them in a resource group. Connect that resource group to the Administrator user group with a context of mgr and they'll be protected in the mgr and unprotected in the front end.

I will supplement BobRay's advice by adding that there is no benefit whatsoever in isolating CSS and JS files into a separate Context. If those CSS/JS Resources are used on all HTML Resources in the web Context, that means you have to load two Contexts on every request to view the Resources in the web Context.

@opengeek: The benefit here is that there is one single location for the css/js which is constant across all contexts (contexts here are acting as subdomains). Because the contexts act as subdomains, to have external css means adjusting for the subdomain when calling for the css/js which became problematic, hence using a specific subdomain. Every change made in the css/js is then reflected across the entire suite, rather than having to make the change for each context. The css/js resources are listed via getResources to save hardcoding.

The alternative is to add the css/js as individual chunks and adding references to those chunks in resources. Could then have copies of the resources in each context all referencing the chunks. This does add another level of resource management however, which just gets annoying, particularly at the resource group stage.

I think I'll just use BobRay's suggestion - I've already set that resource group up. Would be good though to include the securing of the visibility of contexts within the manager without affecting viewability in the front end.

Loading JS and CSS as MODX Resources, although it works, is not an efficient way of delivering JS and CSS content. Having to trigger PHP every time you want to deliver the JS or CSS to a page bypasses the important client-side caching mechanisms built into all modern browsers and configured on all modern web servers.

With that in mind, you can give "load" permission to the Context for anonymous users so anyone can access it on the front-end; to see it in the backend, they will have to have at least the "list" permission as well.

Thanks, I'll give the Load/List thing a try.

Would the same client-side caching issues exist if the css/js resources were Static Resources that linked to their relative files?