AccessDeniedException on publisher instance on node write

[JS_Bournival]

We're having a strange problem on some of our instances.

In some of our template JSPs, we a writing in the repo under /etc/designs/

<% Session session = (resource.getResourceResolver().adaptTo(Session.class)); //... try{ Node n= session.getNode(resourceDesign.getPath()+"/jcr:content/"+template+"/anchors-parsys-layout"); } catch(PathNotFoundException  e){ Node n= session.getNode(resourceDesign.getPath()+"/jcr:content/"+template+"").addNode("anchors-parsys-layout","nt:unstructured"); n.setProperty("components", new String[]{"/apps/corpo/components/content/image", "/apps/corpo/components/content/reference", "/apps/corpo/components/content/textimage", "/apps/corpo/components/content/title", "/apps/corpo/components/content/image-banner/image-banner-render", "/apps/corpo/components/content/text/text", "/apps/corpo/components/content/table"}); n.setProperty("sling:resourceType","foundation/components/parsys"); session.save(); } %>

Unfortunately, this code throwing AccessDeniedException on some of our publish instances.  Moreover, if I log in as admin on those publish instances, it automatically fixes the problem (!)

it's a rather long stacktrace, included as attachment.

Does that rings a bell?  Is this the right way to get the session? If so, does the session have admin rights by default?

Thanks for any help.

JS.

[justin_at_adobe · Accepted solution]

Hi,

It seems unlikely that you want anonymous users to be able to make changes to the design settings (or anything for that matter), so the AccessDeniedException you are getting is to be expected. I'm a little suprised this only happens *some* of the time.

Doing non-UGC content updates from a request thread is generally not a good idea as it either requires granting the end user write access to the repository OR creating an adminstrative session in a request thread which can produce information disclosure issues.

I'd suggest rethinking what it is you are trying to accomplish in such a way that these writes aren't happening in a request context.

Regards,
Justin

[JS_Bournival]

The thing we wanted to accomplish with this is component container: example, tabs.  Within each tab there would be a parsys.  But we wanted those parsys to be already configured to a list of components, thus the dynamic write operation in the design path.

But you are right.  Maybe we designed this the wrong way.  One thing for sure, we modified this code making sure it doesn't mess with all this when in a publish instance, as this is design time meta info, not needed when rendering the page.

Thanks for the advice.

[om_vineet]

Component will always be used in a template. So you can make your use case work by just creating designs for the template where-in you want to use this component. This is not a good idea to have user update /etc/designs as could lead to unwanted errors.