Open up apps directory on publish instance

[christopher_ca9]

For an internal demo site I need to be able to house clientlibs under /apps/ on a per component basis. Replication is working, but it is not viewable to non-admin users who view it on publish. When a user is not admin, client libraries return 404s, and the page does not render appropriately. Housing client libraries under components is discussed as an option under the developer documentation, but it seems to be disabled on publish by default.

I'd like to provide full access to apps on publish also for viewing in crxde-lite and content explorer also. Currently these are hidden from view if not logged in as admin.

I'm aware of the security issues related to blocking apps in favor of etc for client libraries, but this is a special case and a client requirement, and for internal consumption only. It is all behind a company firewall.

Thanks for any assistance,

Matt

[Scott_Brodersen]

You can set the ACL on the apps folder. Use CRXDE Lite, select the folder, and then use the Access Control tab.

The correct way to get around this issue is to create a clientlibraryfolder in /etc, and embed the clientlibraryfolder of each app.

scott

[Jörg_Hoh]

If you have placed your clientlib below /apps, you should create a proxy clientlib somewhere in /apps, e.g /apps/clientlibs. Just create a regular clientlib and make it embed the one you're interested in. Then just request your proxy clientlib and you should be fine.

I wouldn't deal with opening /apps, as it's normally much more work than just creating this new clientlib ... :-)

Jörg

[Paul_McMahon · Accepted solution]

Leaving aside all the security warnings in order to meet your requirements you would have to modify/remove the Global Deny policies that get set on the publish instances. If you look under both /content and /content/apps there are several deny Access Control policies that override any permissions you may have granted to those users. You need to remove or change these deny policies to open up the publish instances. You will have to do this on all your publish instances - you can't do it via replication. 

Best practice for the client lib probably that you are mentioning is to add another layer of abstraction. So you store the client libs in apps with your components, but then you add another client lib in /etc/clientlibs/myapp and do an include of the client lib that is stored with the component. This allows you to store the client libs with the components, but reference them through a publicly available URL. The cq.foundation and cq.foundation-main are an example of this. the cq.foundation category is assigned to multiple client libs that are stored in /libs/foundation/components and the cq.foundation-main client library embeds cq.foundation. Page include cq.foundation-main and all the references go to /etc/clientlibs, but the code is all stored in the components. You can see this at /etc/clientlibs/foundation/main. This example has multiple client libraries being concatenated, but same approach can work for single client libraries. 

[christopher_ca9]

Each of the solutions in this post are correct, although this was eventually corrected by an admin here who added read access to /apps on the "everyone group" in the user admin. Now anyone can view the page and the clientlibs render as expected. This may or may not be the final step though- and I may end up opening using the approach mentioned by altering the access controls.

I considered and was aware of the use of another clientlibs in etc as a proxy which simply embeds the other clientlibs. However, I'm doing some fairly complex and interesting stuff with clientlibs which has multiple layers- and as it turns out there are limits on they types of arrangements you can make using the embed property. Once I do some additional testing I'll link here to an explanation of what those limits are.

Either way these answers helped me. Thanks!!

Matt