Move upgrade help files to xdocs/upgrade.
This commit is contained in:
Ben Alex
parent
2073360037
commit
3b7453d243
|
|
@ -1,47 +1,53 @@
|
|||
===============================================================================
|
||||
ACEGI SECURITY SYSTEM FOR SPRING - UPGRADING FROM 0.3 TO 0.4
|
||||
===============================================================================
|
||||
<html>
|
||||
<head>
|
||||
<title>Acegi Security - Upgrading from version 0.3 to 0.4</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Upgrading from 0.3 to 0.4</h1>
|
||||
|
||||
Several changes were made between version 0.3 and 0.4 of the project.
|
||||
<p>Several changes were made between version 0.3 and 0.4 of the project.
|
||||
These changes increased the modularity of the code, enhanced unit testing,
|
||||
made package roles clearer, and added compelling alternatives to container
|
||||
adapters and using web.xml security constraints to protect HTTP resources.
|
||||
|
||||
Unfortunately, changes to the API and package locations were required. The
|
||||
<p>Unfortunately, changes to the API and package locations were required. The
|
||||
following should help most casual users of the project update their
|
||||
applications:
|
||||
|
||||
- All references to net.sf.acegisecurity.SecurityInterceptor become
|
||||
net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor.
|
||||
<ul>
|
||||
<li>All references to net.sf.acegisecurity.SecurityInterceptor become
|
||||
net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor.</li>
|
||||
|
||||
- All references to net.sf.acegisecurity.MethodDefinitionAttributes become
|
||||
net.sf.acegisecurity.intercept.method.MethodDefinitionAttributes.
|
||||
<li>All references to net.sf.acegisecurity.MethodDefinitionAttributes become
|
||||
net.sf.acegisecurity.intercept.method.MethodDefinitionAttributes.</li>
|
||||
|
||||
- All references to net.sf.acegisecurity.adapters.AutoIntegrationFilter become
|
||||
net.sf.acegisecurity.ui.AutoIntegrationFilter (see your web.xml).
|
||||
<li>All references to net.sf.acegisecurity.adapters.AutoIntegrationFilter become
|
||||
net.sf.acegisecurity.ui.AutoIntegrationFilter (see your web.xml).</li>
|
||||
|
||||
- If you're using container adapters (extremely likely), consider replacing
|
||||
<li>If you're using container adapters (extremely likely), consider replacing
|
||||
them with the net.sf.acegisecurity.ui.webapp package. This will avoid
|
||||
the need to have JARs in your container classloader, and is a lot cleaner.
|
||||
Refer to the reference documentation or Contacts sample application.
|
||||
Refer to the reference documentation or Contacts sample application.</li>
|
||||
|
||||
- If you're using web.xml <security-constraint>s for securing HTTP URLs
|
||||
<li>If you're using web.xml <security-constraint>s for securing HTTP URLs
|
||||
(extremely likely), consider replacing it with the
|
||||
net.sf.acegisecurity.intercept.web package. This will give you considerably
|
||||
more flexibility, and reuse the same concepts as you'd be familiar with
|
||||
via the method security interception system. Refer to the reference
|
||||
documentation or Contacts sample application.
|
||||
documentation or Contacts sample application.</li>
|
||||
|
||||
- The Contacts sample application now builds two distributions: contacts.war
|
||||
<li>The Contacts sample application now builds two distributions: contacts.war
|
||||
can be instantly deployed without configuring any container adapters,
|
||||
whilst contacts-container-adapter.war still uses container adapters. The
|
||||
contacts.war uses the net.sf.acegisecurity.intercept.web package to
|
||||
protect HTTP URLs, rather than web.xml <security-constraint>s.
|
||||
protect HTTP URLs, rather than web.xml <security-constraint>s.</li>
|
||||
|
||||
- If you're using the Jetty container adapter, please check the jetty.xml
|
||||
requirements in the reference documentation. There has been a minor change.
|
||||
<li>If you're using the Jetty container adapter, please check the jetty.xml
|
||||
requirements in the reference documentation. There has been a minor change.</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
We hope you find the new features useful in your projects.
|
||||
|
||||
|
||||
$Id$
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -1,51 +1,59 @@
|
|||
===============================================================================
|
||||
ACEGI SECURITY SYSTEM FOR SPRING - UPGRADING FROM 0.4 TO 0.5
|
||||
===============================================================================
|
||||
<html>
|
||||
<head>
|
||||
<title>Acegi Security - Upgrading from version 0.4 to 0.5</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Upgrading from 0.4 to 0.5</h1>
|
||||
|
||||
The following should help most casual users of the project update their
|
||||
<p>The following should help most casual users of the project update their
|
||||
applications:
|
||||
<ul>
|
||||
|
||||
- All filters are now loaded via FilterToBeanProxy. The FilterToBeanProxy
|
||||
<li>All filters are now loaded via FilterToBeanProxy. The FilterToBeanProxy
|
||||
obtains the filter from a Spring application context via the
|
||||
WebApplicationContextUtils.getApplicationContext() method. Refer to the
|
||||
reference documentation to see the new configuration of filters.
|
||||
reference documentation to see the new configuration of filters.</li>
|
||||
|
||||
- SecurityEnforcementFilter now requires an AuthenticationEntryPoint
|
||||
<li>SecurityEnforcementFilter now requires an AuthenticationEntryPoint
|
||||
and PortResolver. Refer to the reference documentation to see the
|
||||
alternatives AuthenticationEntryPoint implementations available. Simply
|
||||
use the PortResolverImpl for the PortResolver requirement.
|
||||
use the PortResolverImpl for the PortResolver requirement.</li>
|
||||
|
||||
- Any of your login or login failure pages that previously referred to
|
||||
<li>Any of your login or login failure pages that previously referred to
|
||||
AuthenticationProcessingFilter.ACEGI_SECURITY_LAST_EXCEPTION_KEY
|
||||
should now use
|
||||
net.sf.acegisecurity.ui.AbstractProcessingFilter.ACEGI_SECURITY_LAST_EXCEPTION_KEY
|
||||
net.sf.acegisecurity.ui.AbstractProcessingFilter.ACEGI_SECURITY_LAST_EXCEPTION_KEY.</li>
|
||||
|
||||
- DaoAuthenticationProvider no longer provides setters for case sensitivity
|
||||
<li>DaoAuthenticationProvider no longer provides setters for case sensitivity
|
||||
handling. The respective AuthenticationDao implementations should decide
|
||||
whether or not to return User instances reflecting the exact case of the
|
||||
requested username. The new PlaintextPasswordEncoder offers a setter for
|
||||
ignoring the password case (defaults to require exact case matches).
|
||||
ignoring the password case (defaults to require exact case matches).</li>
|
||||
|
||||
- DaoAuthenticationProvider now provides caching. Successful authentications
|
||||
<li>DaoAuthenticationProvider now provides caching. Successful authentications
|
||||
return DaoAuthenticationTokens. You must set the mandatory "key" property
|
||||
on DaoAuthenticationProvider so these tokens can be validated. You may
|
||||
also wish to change the "refreshTokenInterval" property from the default
|
||||
of 60,000 milliseconds.
|
||||
of 60,000 milliseconds.</li>
|
||||
|
||||
- If you're using container adapters, please refer to the reference
|
||||
<li>If you're using container adapters, please refer to the reference
|
||||
documentation as additional JARs are now required in your container
|
||||
classloader.
|
||||
classloader.</li>
|
||||
|
||||
- Whilst not really a change needed to your program, if you're using
|
||||
<li>Whilst not really a change needed to your program, if you're using
|
||||
Acegi Security please consider joining the acegisecurity-developer mailing
|
||||
list. This is currently the best way to keep informed about the project's
|
||||
status and provide feedback in design discussions. You can join at
|
||||
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer.
|
||||
Please continue using the Spring Users mailing list for general support.
|
||||
Please continue using the Spring Users mailing list for general support.</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
There are also lots of new features you might wish to consider for your
|
||||
projects. These include CAS integration, pluggable password encoders
|
||||
(such as MD5 and SHA), along with pluggable salt sources. We hope you find
|
||||
the new features useful in your projects.
|
||||
|
||||
$Id$
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
<html>
|
||||
<head>
|
||||
<title>Acegi Security - Upgrading from version 0.3 to 0.4</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Upgrading from 0.5 to 0.6</h1>
|
||||
|
||||
<p>
|
||||
The following should help most casual users of the project update their
|
||||
applications:
|
||||
<ul>
|
||||
<li>
|
||||
Locate and remove all property references to
|
||||
DaoAuthenticationProvider.key and
|
||||
DaoAuthenticationProvider.refreshTokenInterval.</li>
|
||||
|
||||
<li>If you are using DaoAuthenticationProvider and either (i) you are using
|
||||
container adapters or (ii) your code relies on the Authentication object
|
||||
having its getPrincipal() return a String, you must set the new
|
||||
DaoAuthenticationProvider property, forcePrincipalAsString, to true.
|
||||
By default DaoAuthenticationProvider returns an Authentication object
|
||||
containing the relevant User, which allows access to additional properties.
|
||||
Where possible, we recommend you change your code to something like this,
|
||||
so that you can leave forcePrincipalAsString to the false default:<br><br>
|
||||
<code>
|
||||
String username = authentication.getPrincipal();<br>
|
||||
if (authentication.getPrincipal() instanceof User) {<br>
|
||||
username = ((User) authentication.getPrincipal()).getUsername();<br>
|
||||
}</br>
|
||||
</code><br>
|
||||
</li>
|
||||
|
||||
<li>The signature of AuthenticationDaos have changed. In concrete
|
||||
implementations, modify the User to UserDetails, as shown below:<br><br>
|
||||
<code>
|
||||
public User loadUserByUsername(String username)<br>
|
||||
throws UsernameNotFoundException, DataAccessException {<br><br>
|
||||
|
||||
to:<br><br>
|
||||
|
||||
public UserDetails loadUserByUsername(String username)<br>
|
||||
throws UsernameNotFoundException, DataAccessException {<br><br>
|
||||
</code>
|
||||
|
||||
Existing concrete implementations would be returning User, which implements
|
||||
UserDetails, so no further code changes should be required.
|
||||
</li>
|
||||
<li>Similar signature changes (User -> UserDetails) are also required to any
|
||||
custom implementations of UserCache and SaltSource.</li>
|
||||
|
||||
<li>Any custom event listeners relying on AuthenticationEvent should note a
|
||||
UserDetails is now provided in the AuthenticationEvent (not a User).</li>
|
||||
|
||||
<li>CAS users should note the CasAuthoritiesPopulator interface signature has
|
||||
changed. Most CAS users will be using DaoCasAuthoritiesPopulator, so this
|
||||
change is unlikely to require any action.</li>
|
||||
|
||||
<li>Please check your web.xml for whether you are using AutoIntegrationFilter.
|
||||
Previously this class was loaded directly by web.xml as a filter. It is
|
||||
now recommended to load it via FilterToBeanProxy and define it as a
|
||||
bean in your application context. This usually involves making the entry
|
||||
in web.xml match the following:<br><br>
|
||||
<code>
|
||||
<filter><br>
|
||||
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name><br>
|
||||
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class><br>
|
||||
<init-param><br>
|
||||
<param-name>targetClass</param-name><br>
|
||||
<param-value>net.sf.acegisecurity.ui.AutoIntegrationFilter</param-value><br>
|
||||
</init-param><br>
|
||||
</filter><br>
|
||||
</code>
|
||||
<br><br>
|
||||
Then add the following to applicationContext.xml: <br><br>
|
||||
<code>
|
||||
<bean id="autoIntegrationFilter" class="net.sf.acegisecurity.ui.AutoIntegrationFilter"/><br>
|
||||
</code>
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -1,11 +1,15 @@
|
|||
===============================================================================
|
||||
ACEGI SECURITY SYSTEM FOR SPRING - UPGRADING FROM 0.6 TO 0.7
|
||||
===============================================================================
|
||||
<html>
|
||||
<head>
|
||||
<title>Acegi Security - Upgrading from version 0.6 to 0.7</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Upgrading from 0.6 to 0.7</h1>
|
||||
|
||||
<p>
|
||||
The following should help most casual users of the project update their
|
||||
applications:
|
||||
|
||||
- MethodDefinitionMap, which is usually used by MethodSecurityInterceptor
|
||||
<ul>
|
||||
<li>MethodDefinitionMap, which is usually used by MethodSecurityInterceptor
|
||||
for its objectDefinitionSource property, has been changed. From 0.7, when
|
||||
MethodDefinitionMap is queried for configuration attributes associated with
|
||||
secure MethodInvocations, it will use any method matching in the method
|
||||
|
|
@ -17,18 +21,19 @@ applications:
|
|||
As we have always encouraged definition against the interface names (as per
|
||||
this example), this change should not adversely impact users. This change
|
||||
was necessary because of the new MethodDefinitionSourceAdvisor (see below).
|
||||
Refer to the MethodDefinitionMap JavaDocs for further clarification.
|
||||
Refer to the MethodDefinitionMap JavaDocs for further clarification.</li>
|
||||
|
||||
- MethodDefinitionSourceAdvisor can now be used instead of defining proxies
|
||||
<li>MethodDefinitionSourceAdvisor can now be used instead of defining proxies
|
||||
for secure business objects. The advisor is fully compatible with both
|
||||
MethodDefinitionMap and MethodDefinitionAttributes. Using an advisor allows
|
||||
caching of which methods the MethodSecurityInterceptor should handle, thus
|
||||
providing a performance benefit as MethodSecurityInterceptor is not called
|
||||
for public (non-secure) objects. It also simplifies configuration.
|
||||
for public (non-secure) objects. It also simplifies configuration.</li>
|
||||
|
||||
- MethodSecurityInterceptor has moved from
|
||||
<li>MethodSecurityInterceptor has moved from
|
||||
net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor to
|
||||
net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor.
|
||||
A simple find and replace will suffice to update your application contexts.
|
||||
|
||||
$Id$
|
||||
A simple find and replace will suffice to update your application contexts.</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
===============================================================================
|
||||
ACEGI SECURITY SYSTEM FOR SPRING - UPGRADING FROM 0.5 TO 0.6
|
||||
===============================================================================
|
||||
|
||||
The following should help most casual users of the project update their
|
||||
applications:
|
||||
|
||||
- Locate and remove all property references to
|
||||
DaoAuthenticationProvider.key and
|
||||
DaoAuthenticationProvider.refreshTokenInterval.
|
||||
|
||||
- If you are using DaoAuthenticationProvider and either (i) you are using
|
||||
container adapters or (ii) your code relies on the Authentication object
|
||||
having its getPrincipal() return a String, you must set the new
|
||||
DaoAuthenticationProvider property, forcePrincipalAsString, to true.
|
||||
By default DaoAuthenticationProvider returns an Authentication object
|
||||
containing the relevant User, which allows access to additional properties.
|
||||
Where possible, we recommend you change your code to something like this,
|
||||
so that you can leave forcePrincipalAsString to the false default:
|
||||
|
||||
String username = authentication.getPrincipal();
|
||||
if (authentication.getPrincipal() instanceof User) {
|
||||
username = ((User) authentication.getPrincipal()).getUsername();
|
||||
}
|
||||
|
||||
- The signature of AuthenticationDaos have changed. In concrete
|
||||
implementations, modify the User to UserDetails, as shown below:
|
||||
|
||||
public User loadUserByUsername(String username)
|
||||
throws UsernameNotFoundException, DataAccessException {
|
||||
|
||||
to:
|
||||
|
||||
public UserDetails loadUserByUsername(String username)
|
||||
throws UsernameNotFoundException, DataAccessException {
|
||||
|
||||
Existing concrete implementations would be returning User, which implements
|
||||
UserDetails, so no further code changes should be required.
|
||||
|
||||
- Similar signature changes (User -> UserDetails) are also required to any
|
||||
custom implementations of UserCache and SaltSource.
|
||||
|
||||
- Any custom event listeners relying on AuthenticationEvent should note a
|
||||
UserDetails is now provided in the AuthenticationEvent (not a User).
|
||||
|
||||
- CAS users should note the CasAuthoritiesPopulator interface signature has
|
||||
changed. Most CAS users will be using DaoCasAuthoritiesPopulator, so this
|
||||
change is unlikely to require any action.
|
||||
|
||||
- Please check your web.xml for whether you are using AutoIntegrationFilter.
|
||||
Previously this class was loaded directly by web.xml as a filter. It is
|
||||
now recommended to load it via FilterToBeanProxy and define it as a
|
||||
bean in your application context. This usually involves making the entry
|
||||
in web.xml match the following:
|
||||
|
||||
<filter>
|
||||
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
|
||||
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
|
||||
<init-param>
|
||||
<param-name>targetClass</param-name>
|
||||
<param-value>net.sf.acegisecurity.ui.AutoIntegrationFilter</param-value>
|
||||
</init-param>
|
||||
</filter>
|
||||
|
||||
Then add the following to applicationContext.xml:
|
||||
|
||||
<bean id="autoIntegrationFilter" class="net.sf.acegisecurity.ui.AutoIntegrationFilter" />
|
||||
|
||||
|
||||
$Id$
|
||||
Loading…
Reference in New Issue