AccessDeniedException on publisher instance on node write | Community
Skip to main content
JS_Bournival
JS_Bournival
Level 3
October 16, 2015
Solved

AccessDeniedException on publisher instance on node write

  • October 16, 2015
  • 3 replies
  • 1705 views

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.

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by JustinEd3

    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

    3 replies

    J
    Adobe Employee
    JustinEd3Adobe EmployeeAccepted solution
    Adobe Employee
    October 16, 2015

    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
      JS_BournivalAuthor
      Level 3
      October 16, 2015

      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.

      O
      om_vineet
      Level 2
      October 16, 2015

      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.

      Terms & ConditionsAccessibility statement

      Loading footer...