I have already tried that approach but unfortunately it will not work for us. Here is a scenario -
UserA has previlige to replicate /content/aa/* paths.
UserB has previlige to replicate /content/aa/bb/* paths.
When UserA requests for a page activation lets say /content/aa/page.html, the request will still go through. Even if I setup UserA with "deny" previlige on /content/aa/bb path, the user's default allow previlige will override it.
The problem essentially is that we have 2 separate publish instances where we need different content loaded.
PublishInstanceA will host everything under /content EXCEPT for /content/aa/bb/* paths.
PublishInstanceB will host ONLY /content/aa/bb/* paths. All other paths should be ignored.
Furthermore - admin user by default has previlige to replicate everything under the root node.
I hope that clarifies the issue that we are facing.
When a page is going to be published, it is first checked against the access rights of the configured "agent user"; if the agent user can read that page, this page will be put to the replication queue.
This is the documented and working way to restrict replication agents only to replicate certain parts of the repository.
Thanks for the response. It does kind of works, but it will be hard to identify which one are genuinely rejected content for replication & the authentication failed one's.
And remember this has to be managed for reverse replication as well. So there will be always be a bunch of items in the queue re-trying to publish.
If someone publishes a content, what CQ does at the moment is, it hands over the content to all the agents configured and let the agents determine what access rights they have.
But it would be nice if there's a middle man process, who hands over the content to the appropriate agent. Because I believe there should be loads of clients trying to have both intranet and internet sites delivered through a single platform. The current architecture doesn't allows to mark contents as intranet specific one's and internet specific one's.
I know some cases, where different frontend systems need to be delivered by a central authoring system. In these cases the content is usually structured in a way, so that you can easily determine, if a page will go to intranet or internet:
- Internet content is located in /content/internet/
- Intranet content is located in /content/intranet/
Because then the settings are straight forward. If you need to maintain pages in both trees, I would recommend you to use the MSM.
In any case, that's the way how it works, and I have never experienced major problems with it, neither in functionality nor in maintainability. Of course you can request such an extension via Daycare support. But I wouldn't expect too much, as this would be a very intrusive change in a core functionality.