Spring Security
  1. Spring Security
  2. SEC-525

[PATCH] Add AccessCheckerTag based on URL resource access permissions.

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.5
    • Fix Version/s: 3.0.0 RC1
    • Component/s: Taglibs
    • Labels:
      None

      Description

      I have developed a tag (AccessCheckerTag) based on URL and not in roles, which reuse objectDefinitionSource (urls + roles) and accessDecisionManager (voters) of the filterInvocationInterceptor bean, inspired in AuthorizeTag and AccessControlListTag.

      jsp looks like this:
      <authz:accesschecker url="/deletePerson.do">
      <A HREF="<c:out value="$

      {request.contextPath}

      " />/deletePerson.do?id=<c:out value="$

      {person.id}

      " />">Del</A>
      </authz:accesschecker>

      I consider that this tag can be useful for some cases in which before printing the html link or button it is necessary to verify if required access is had to url resource.

      see: http://forum.springframework.org/showthread.php?t=42550

        Issue Links

          Activity

          Hide
          Ezequiel Chávez added a comment -

          tag section of the tld

          <tag>
          <name>accesschecker</name>
          <tag-class>org.acegisecurity.taglibs.authz.AccessCheckerTag</tag-class>
          <description>
          A simple tag to output or not the body of the tag if the principal
          has or doesn't have access to URL resource.
          </description>

          <attribute>
          <name>url</name>
          <required>true</required>
          <rtexprvalue>true</rtexprvalue>
          <description>
          An URL resource without specifying the contextPath, which the user must have access
          for the body to be output.
          </description>
          </attribute>
          </tag>

          Show
          Ezequiel Chávez added a comment - tag section of the tld <tag> <name>accesschecker</name> <tag-class>org.acegisecurity.taglibs.authz.AccessCheckerTag</tag-class> <description> A simple tag to output or not the body of the tag if the principal has or doesn't have access to URL resource. </description> <attribute> <name>url</name> <required>true</required> <rtexprvalue>true</rtexprvalue> <description> An URL resource without specifying the contextPath, which the user must have access for the body to be output. </description> </attribute> </tag>
          Hide
          Eric Bottard added a comment -

          I haven't had a look at the actual code, but I must say I find the idea of this tag to be a Good Thing (tm) :

          indeed it allows to enforce the DRY principle where the configuration of which authorities are needed to access a particular URL is not repeadted (whereas with the traditional tags approach it would reside in the filter definition + in the JSP page). IMO, the JSP page should not know about roles, etc.

          +1 then

          Regards,
          eb.

          Show
          Eric Bottard added a comment - I haven't had a look at the actual code, but I must say I find the idea of this tag to be a Good Thing (tm) : indeed it allows to enforce the DRY principle where the configuration of which authorities are needed to access a particular URL is not repeadted (whereas with the traditional tags approach it would reside in the filter definition + in the JSP page). IMO, the JSP page should not know about roles, etc. +1 then Regards, eb.
          Hide
          Willie Wheeler added a comment -

          I can see this being used to promote DRY, though enforce might be too strong. There are times when you want to display links that the user isn't currently authorized to access. Here are two examples:

          1) You'd want to show all users (including unauthenticated users) the Checkout link in an e-commerce app, even if the checkout requires authentication. Admittedly, in this case you wouldn't use a tag at all, but it does highlight the fact that display != access.

          2) Another example might be displaying a premium content on a site that offers basic content to basic accounts and premium content to premium users. In this case you might plausibly use a tag to show the premium content link only to basic and premium users (no anonymous users). When a basic user clicks on the premium content link, he's given the opportunity to upgrade his account.

          Anyway, just wanted to point out that display and access, though obviously related, aren't entirely coincident. (So I think we'd want to retain the old tags even when the new one is added.) I still think the tag is a good idea though because in plenty of individual cases display and access are coincident.

          Show
          Willie Wheeler added a comment - I can see this being used to promote DRY, though enforce might be too strong. There are times when you want to display links that the user isn't currently authorized to access. Here are two examples: 1) You'd want to show all users (including unauthenticated users) the Checkout link in an e-commerce app, even if the checkout requires authentication. Admittedly, in this case you wouldn't use a tag at all, but it does highlight the fact that display != access. 2) Another example might be displaying a premium content on a site that offers basic content to basic accounts and premium content to premium users. In this case you might plausibly use a tag to show the premium content link only to basic and premium users (no anonymous users). When a basic user clicks on the premium content link, he's given the opportunity to upgrade his account. Anyway, just wanted to point out that display and access, though obviously related, aren't entirely coincident. (So I think we'd want to retain the old tags even when the new one is added.) I still think the tag is a good idea though because in plenty of individual cases display and access are coincident.
          Hide
          Andy Li added a comment -

          I did see this tag being added in the release notes of spring-security-3.0.0, but in the jar files shipped with the 3.0.0.M1, it is not there... is it gonna be added soon?

          Show
          Andy Li added a comment - I did see this tag being added in the release notes of spring-security-3.0.0, but in the jar files shipped with the 3.0.0.M1, it is not there... is it gonna be added soon?
          Hide
          Luke Taylor added a comment -

          The tag libraries in general need to be redone and improved. There are several issues which need to be addressed. I don't know exactly when it will happen as there are lots of other things we have to do.

          Show
          Luke Taylor added a comment - The tag libraries in general need to be redone and improved. There are several issues which need to be addressed. I don't know exactly when it will happen as there are lots of other things we have to do.
          Hide
          Luke Taylor added a comment -

          I've implemented this in the standard "authorize" tag. So it can now take a URL as an attribute as an alternative to using an expression:

          <sec:authorize url='/secure/index.jsp'>
          ...
          </sec:authorize>

          The <http> namespace element now registers a WebInvocationPrivilegeEvaluator in the application context and the tag makes use of this in determining whether access is allowed.

          Show
          Luke Taylor added a comment - I've implemented this in the standard "authorize" tag. So it can now take a URL as an attribute as an alternative to using an expression: <sec:authorize url='/secure/index.jsp'> ... </sec:authorize> The <http> namespace element now registers a WebInvocationPrivilegeEvaluator in the application context and the tag makes use of this in determining whether access is allowed.
          Hide
          Chandramohan added a comment -

          Which version of Spring has this fix ?

          Show
          Chandramohan added a comment - Which version of Spring has this fix ?

            People

            • Assignee:
              Luke Taylor
              Reporter:
              Ezequiel Chávez
            • Votes:
              6 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: