Don't have CRXDE access

The issue is with /conf directory. Remove read permissions on /conf directory and try.

This seems to be a totally different issue (just by looking at the description), can you please raise a new thread here in the forum? Thanks!

I had seen the same problem and created an adobe ticket. If you open the browser debug window, you will see there is javascript error:

TreeLoader.js:153 TypeError: Cannot read property 'properties' of undefined

    at getMergedPropertyDefinitions (NodetypeRegistry.js:53)

    at NodetypeRegistry.js:122

    at Array.each (Ext.js:43)

    at Object.getPropertyDefinitions (NodetypeRegistry.js:120)

    at constructor.processNewChild (RepositoryTree.TreeLoader.js:56)

    at Object.<anonymous> (TreeLoader.js:142)

    at Object.each (ext-base-debug.js:407)

    at constructor.processResponse (TreeLoader.js:139)

    at constructor.handleResponse (ext-all-debug.js:47781)

    at Ext.data.Connection.handleResponse (ext-all-debug.js:8550)

I think adobe should fix that, since user has enough permission to view those content, and login as admin does work without js error.

You might consider it useful to have; but there is a reason why the official security checklist recommends to disable the CRXDE Bundle! I don't really agree to recommendation, because for debugging purposes CRXDE has proven its value. But definitely not for performing changes in PROD.

I would hope that they can only replicate via crx/de if they have replicate permissions on the node (I have not verified this, but it seems like something the system would prevent a user from doing if they don't have replicate access to the node). Technically, a savvy enough user could also just send the appropriate REST operation to do what crx/de is doing and if they have permissions, the system will allow it.

I am not advocating and advertising this to our end users, but it is a lot easier for some people to see how the page is created and then copy sections of the page via crx/de. For example, when I created a complex page that had a lot of reference links to other content embedded in other components, it was easier and faster for me to copy a node that defined the component and paste / change that node in crx/de than it would have been via the editor.html interface. Since I had value out of crx/de, I find it hard to prevent other people from getting a similar value out of it. 

I do agree that it allows them to bypass business processes and other policies / checks in place for field values. All that being said, it isn't being used all the time by the powerusers. It is more of a helpful tool for them to troubleshoot any problems that they may not see in the editor or preview modes. Thanks for the explanation about the cause of this change!

With 6.4 there was some problem with login on CRXDE Lite if you don't have read permissions on /conf (or something like that, was a weird permission thing). Daycare should know that topic and should be able to help you.

Anyway, if your powerusers work directly on CRXDE Lite and modify nodes and properties, I wonder why you need AEM at all. They are using the system in a way, which is hardly controllable (the only constraints are permissions, but everything else is totally free to them), and therefor they can bypass many processes you have provided to authors. For example, in CRXDE Lite they can trigger replication and bypass any approval workflow.

I do not recommend that approach at all. Access to CRXDE should always be restricted.

While I agree only Admins should have access to CRX DE, in practice, our "power users" find that they can do more when they have access to it (ie. change content / page templates / properties directly).  I created a group that has access to crx/de by setting the permissions to be "Read" on "/" and "conf" (I did not need that group to have read on the etc or home directories but YMMV). 

Additionally, I noticed that if I added a person to the "operators" group, they would have access to crxde, but I can't seem to locate any documentation on what the "operators" group in AEM does (The node permissions seem very restrictive, but I don't know if they had additional permissions on osgi bundles).

Exactly -- only admin should have access to CRXDE lite. Authors have access to Touch UI views - like Site admin.

This does work.  Though I'm not sure why since the permissions to the paths are the same as the content author group.

I've also confirmed that with the custom group and the content author group added for the test user, that crx/de access is maintained. 

With further testing of the above I found the solution will be to create a custom group called "crxde-access" or something of the sort and manually grant permissions to it as above.  Then assign that "crxde-access" group to the content authors group.  This allows all content authors access to crx/de folders, as well as editing rights in crx/de in the content directory.