Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-525: [PATCH] Add AccessCheckerTag based on URL resource access permissions. #787

spring-issuemaster opened this Issue Aug 14, 2007 · 7 comments


None yet
1 participant

Ezequiel Chávez(Migrated from SEC-525) said:

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:

<A HREF=“”${request.contextPath}" />/deletePerson.do?id=">Del

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

Ezequiel Chávez said:

tag section of the tld

accesschecker org.acegisecurity.taglibs.authz.AccessCheckerTag A simple tag to output or not the body of the tag if the principal has or doesn’t have access to URL resource.



An URL resource without specifying the contextPath, which the user must have access
for the body to be output.


Eric Bottard said:

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™ :

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


Willie Wheeler said:

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.

Andy Li said:

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?

Luke Taylor said:

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.

Luke Taylor said:

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'>

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

Chandramohan said:

Which version of Spring has this fix ?

@spring-issuemaster spring-issuemaster added this to the 3.0.0 RC1 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment