Raible's Wiki

Raible Designs
Wiki Home
News
Recent Changes

AppFuse

Homepage
  - Korean
  - Chinese
  - Italian
  - Japanese

QuickStart Guide
  - Chinese
  - French
  - German
  - Italian
  - Korean
  - Portuguese
  - Spanish
  - Japanese

User Guide
  - Korean
  - Chinese

Tutorials
  - Chinese
  - German
  - Italian
  - Korean
  - Portuguese
  - Spanish

FAQ
  - Korean

Latest Downloads

Other Applications

Struts Resume
Security Example
Struts Menu

Set your name in
UserPreferences


Referenced by
AppFuseSecurity
AppFuseSecurityMetho...




JSPWiki v2.2.33

[RSS]


Hide Menu

AppFuseSecurityMethods


Difference between version 14 and version 5:

At line 1 removed 2 lines.
!!!This document is a work in progress, don't count on this actually working yet.
At line 5 changed 1 line.
Acegi Security is a security framework that is build using the techniques of the [Spring Framework|http://springframework.org] and is made to integrate easily into projects that utilize Spring, such as any application built on AppFuse 1.4 or newer (if your AppFuse app is older than 1.4 there is a tutorial for [migrating your app to use the Spring Framework|AppFuseSpringUpgrade]). The first level of Acegi integration into AppFuse is [authentication|AppFuseAuthentication] and authorization to access URI's based on user ''roles'', and this tutorial will assume you have already completed the migration from container managed security to use Acegi authentication. The next level is to grant or deny user access to methods of our service classes based on the user's role(s). Once you have completed this you may want to go on to adding [Access Control List authorization|AppFuseSecurityACL] for a more fine grained control.
Acegi Security is a security framework that is build using the techniques of the [Spring Framework|http://springframework.org] and is made to integrate easily into projects that utilize Spring, such as any application built on AppFuse 1.4 or newer (if your AppFuse app is older than 1.4 there is a tutorial for [migrating your app to use the Spring Framework|AppFuseSpringUpgrade]). The first level of Acegi integration into AppFuse is [authentication|AppFuseAuthentication] and authorization to access URI's based on user ''roles'', and this tutorial will assume you have already completed the migration from container managed security to use Acegi authentication. The next level is to grant or deny user access to methods of our service classes based on the user's role(s). Once you have completed this you may want to go on to [Part II|AppFuseSecurityMethods2] or add [Access Control List authorization|AppFuseSecurityACL] for a more fine grained control.
At line 13 added 1 line.
* [6] Test that it all works
At line 29 added 1 line.
}}}
At line 31 changed 2 lines.
...
[{Java2HtmlPlugin
At line 114 changed 1 line.
}}}
}]
At line 116 changed 2 lines.
The second consideration for Actions is that public actions (any action that does not require the user to be logged on) can only access public methods on our manager beans and the resulting {{success}} page can only access public methods. When AppFuse comes out of the box the only action that needs to be modified is {{SignupAction}}. We will need to remove the code that ''automagically'' used to log in a user after signup. It would be possible to still do this, but it is fairly complicated and it's not really that important to me to make the user not have to log in right after creating his account. But the problem with leaving that code in is that is would cause one of the decorator pages to try and access UserManager.getUser() which is protected. This will cause an AccessDeniedException to be thrown since our user is not yet logged in. So remove this section of code from {{SignupAction}}:
{{{ // Set cookies for auto-magical login ;-)
The second consideration for Actions is that public actions (any action that does not require the user to be logged on) can only access public methods on our manager beans and the resulting {{success}} page can only access public methods. When AppFuse comes out of the box the only action that needs to be modified is {{SignupAction}}. We will need to remove the code that ''automagically'' used to log in a user after signup. It would be possible to still do this, but it is fairly complicated and it's not really that important to me to make the user not have to log in right after creating his account. But the problem with leaving that code in is that it would cause one of the decorator pages to try and access UserManager.getUser() which is protected. This will cause an AccessDeniedException to be thrown since our user is not yet logged in. So remove this section of code from {{SignupAction}}:
[{Java2HtmlPlugin
// Set cookies for auto-magical login ;-)
At line 120 changed 1 line.
loginCookie, request.getContextPath());}}}
loginCookie, request.getContextPath());
}]
At line 122 removed 1 line.
At line 170 changed 1 line.
You can see that I added those comment tags so we can remove the method security during the unit tests.
You can see the comment tags surrounding the interceptor so we can remove the method security during the unit tests.
At line 173 changed 1 line.
Now we need to modify {{build.xml}} so the Method Security interceptor will be removed during the unit tests.
Now we need to modify {{build.xml}} to take advantage of those comment tags we just added to {{applicationContext-security.xml}}. In the {{test-module}} target we need to add a regular expression replace task to remove the XML between out comment tags. I changed the beginning of {{test-module}} target to look like this:
{{{ <target name="test-module">
<!-- Inputs: module, test.classpath -->
<echo level="info">Testing ${module}...</echo>
<mkdir dir="${test.dir}/data"/>
<propertycopy name="testcase" from="${module}-testcase" silent="true"/>
<!-- Replace tokens in test properties files -->
<copy todir="${test.dir}/${module}/classes">
<fileset dir="test/${module}" excludes="**/*.java"/>
<filterset refid="variables.to.replace"/>
</copy>
<!-- Use test-specific XML files -->
<copy todir="${webapp.target}/WEB-INF" overwrite="true">
<fileset dir="test" includes="*.xml"/>
</copy>
<!-- Remove configurations that should not be enabled during testing -->
<replaceregexp file="${webapp.target}/WEB-INF/applicationContext-service.xml"
flags="sg">
<regexp pattern="REMOVE DURING TEST: Start.*REMOVE DURING TEST: End" />
<substitution expression="REMOVED DURING TESTING" />
</replaceregexp>
<property name="additional.src.dirs" value=""/>
<junit ... }}}
!!Test that it all works [#6]
At this point we should be able to successfully run an {{ant test-all}}. The unit tests will not use the security, but the web tests will. So if you want to make sure a user cannot do something they should not be allowed to you can add a test to web-tests.xml. But if you want to see that the security works, log in as user "tomcat" and try to access [http://localhost:8080/appfuse/editProfile.html?method=search]. Because we reqire an {{admin}} role to access {{UserManager.getUsers}} you should now get a 403 Access Denied error.
Now that Acegi Method Invocation authorization is in our application and working we will need to make it grant access based on more than what roles a user has been given. For example we need to make sure a user with only the {{tomcat}} role can only use {{UserManager.getUser()}} to retreive his own account information, and {{UserManager.saveUser()}} only to update his profile. So that is our task in [Part II|AppFuseSecurityMethods2] of this tutorial.

Back to AppFuseSecurityMethods, or to the Page History.