Page History

Page level security

One may also configure a mapping of roles to page urls. In the example above where we were testing if a user had the instructor role before showing them a page to select sections to view, instead of writing code, we could have  declared our protection like this:

	<bean id="filterSecurityInterceptor" class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">
		<property name="authenticationManager" ref="authenticationManager"/>
		<property name="accessDecisionManager" ref="accessDecisionManager"/>
                <property name="securityMetadataSource">
                   <security:filter-security-metadata-source>
                         <security:intercept-url pattern="/advisor_reg_summary.htm" access="ROLE_OREG_REGISTRAR,ROLE_OREG_DEPT_ADMIN,ROLE_OREG_ADVISOR" />
                         <security:intercept-url pattern="/agreement.htm" access="ROLE_CURRENT_STUDENT" />
                   </security:filter-security-metadata-source>
                </property>
        </bean>

and the Spring Security framework would have invoked the access denied handler when a user who did not have this role tried to access the page. We could then write the access denied handler to show a page with a friendly message or perhaps redirect the user somewhere they are supposed to be instead.

The "pattern" attributes specify which URL(s) are to be restricted. Patterns can specify a specific page, as in the above examples, or can specify a range of URLs via wildcards. For example, the following pattern would restrict all pages under the "admin" folder to users with the "ADMIN" role:

    <security:intercept-url pattern="/admin/*" access="ROLE_ADMIN" />

Overlapping patterns can also be specified: the latter-defined patterns will override the earlier patterns. An example of this usage would be a section of a web site generally restricted to DINING users, but with certain pages also open to REGISTRAR users. We would define a general pattern to implement the DINING users restriction, and a second more specific pattern giving the REGISTRAR users access to particular pages:

    <security:intercept-url pattern="/dining/*" access="ROLE_DINING" />
    <security:intercept-url pattern="/dining/some_shared_page.htm" access="ROLE_DINING,ROLE_REGISTRAR" />