SEC-540: Moved announcements and upgrade directories from doc module to src/site.
This commit is contained in:
parent
699f5389f4
commit
31360ecce6
|
@ -1,16 +1,10 @@
|
|||
<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>
|
||||
|
||||
<p>Several changes were made between version 0.3 and 0.4 of the project.
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<document><properties><title>Acegi Security - Upgrading from version 0.3 to 0.4</title></properties><body><section name="Upgrading from 0.3 to 0.4"><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.
|
||||
|
||||
<p>Unfortunately, changes to the API and package locations were required. The
|
||||
</p><p>Unfortunately, changes to the API and package locations were required. The
|
||||
following should help most casual users of the project update their
|
||||
applications:
|
||||
|
||||
|
@ -34,20 +28,21 @@ applications:
|
|||
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.</li>
|
||||
documentation or Contacts sample application.</security-constraint></li>
|
||||
|
||||
<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.</li>
|
||||
protect HTTP URLs, rather than web.xml <security-constraint>s.</security-constraint></li>
|
||||
|
||||
<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>
|
||||
</p><p>
|
||||
We hope you find the new features useful in your projects.
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
</p></section></body></document>
|
|
@ -1,11 +1,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>
|
||||
|
||||
<p>The following should help most casual users of the project update their
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<document><properties><title>Acegi Security - Upgrading from version 0.4 to 0.5</title></properties><body><section name="Upgrading from 0.4 to 0.5"><p>The following should help most casual users of the project update their
|
||||
applications:
|
||||
<ul>
|
||||
|
||||
|
@ -48,12 +42,13 @@ applications:
|
|||
Please continue using the Spring Users mailing list for general support.</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
</p><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.
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
</p></section></body></document>
|
|
@ -1,11 +1,5 @@
|
|||
<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>
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<document><properties><title>Acegi Security - Upgrading from version 0.3 to 0.4</title></properties><body><section name="Upgrading from 0.5 to 0.6"><p>
|
||||
The following should help most casual users of the project update their
|
||||
applications:
|
||||
<ul>
|
||||
|
@ -21,31 +15,31 @@ Locate and remove all property references to
|
|||
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>
|
||||
so that you can leave forcePrincipalAsString to the false default:<br></br><br></br>
|
||||
<code>
|
||||
String username = authentication.getPrincipal();<br>
|
||||
if (authentication.getPrincipal() instanceof User) {<br>
|
||||
username = ((User) authentication.getPrincipal()).getUsername();<br>
|
||||
}</br>
|
||||
</code><br>
|
||||
String username = authentication.getPrincipal();<br></br>
|
||||
if (authentication.getPrincipal() instanceof User) {<br></br>
|
||||
username = ((User) authentication.getPrincipal()).getUsername();<br></br>
|
||||
}
|
||||
</code><br></br>
|
||||
</li>
|
||||
|
||||
<li>The signature of AuthenticationDaos have changed. In concrete
|
||||
implementations, modify the User to UserDetails, as shown below:<br><br>
|
||||
implementations, modify the User to UserDetails, as shown below:<br></br><br></br>
|
||||
<code>
|
||||
public User loadUserByUsername(String username)<br>
|
||||
throws UsernameNotFoundException, DataAccessException {<br><br>
|
||||
public User loadUserByUsername(String username)<br></br>
|
||||
throws UsernameNotFoundException, DataAccessException {<br></br><br></br>
|
||||
|
||||
to:<br><br>
|
||||
to:<br></br><br></br>
|
||||
|
||||
public UserDetails loadUserByUsername(String username)<br>
|
||||
throws UsernameNotFoundException, DataAccessException {<br><br>
|
||||
public UserDetails loadUserByUsername(String username)<br></br>
|
||||
throws UsernameNotFoundException, DataAccessException {<br></br><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
|
||||
<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
|
||||
|
@ -59,23 +53,24 @@ Locate and remove all property references to
|
|||
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>
|
||||
in web.xml match the following:<br></br><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>
|
||||
<filter><br></br>
|
||||
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name><br></br>
|
||||
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class><br></br>
|
||||
<init-param><br></br>
|
||||
<param-name>targetClass</param-name><br></br>
|
||||
<param-value>net.sf.acegisecurity.ui.AutoIntegrationFilter</param-value><br></br>
|
||||
</init-param><br></br>
|
||||
</filter><br></br>
|
||||
</code>
|
||||
<br><br>
|
||||
Then add the following to applicationContext.xml: <br><br>
|
||||
<br></br><br></br>
|
||||
Then add the following to applicationContext.xml: <br></br><br></br>
|
||||
<code>
|
||||
<bean id="autoIntegrationFilter" class="net.sf.acegisecurity.ui.AutoIntegrationFilter"/><br>
|
||||
<bean id="autoIntegrationFilter" class="net.sf.acegisecurity.ui.AutoIntegrationFilter"/><br></br>
|
||||
</code>
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
</p></section></body></document>
|
|
@ -1,11 +1,5 @@
|
|||
<html>
|
||||
<head>
|
||||
<title>Acegi Security - Upgrading from version 0.6 to 0.7</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Upgrading from 0.6 to 0.7.0</h1>
|
||||
|
||||
<p>
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<document><properties><title>Acegi Security - Upgrading from version 0.6 to 0.7</title></properties><body><section name="Upgrading from 0.6 to 0.7.0"><p>
|
||||
The following should help most casual users of the project update their
|
||||
applications:
|
||||
<ul>
|
||||
|
@ -56,5 +50,6 @@ be correct.
|
|||
Note the "cache" property is now required, and the old internally-managed
|
||||
cache properties have been removed.</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
</p></section></body></document>
|
|
@ -1,11 +1,5 @@
|
|||
<html>
|
||||
<head>
|
||||
<title>Acegi Security - Upgrading from version 0.7.0 to 0.8.0</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Upgrading from 0.7.0 to 0.8.0</h1>
|
||||
|
||||
<p>
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<document><properties><title>Acegi Security - Upgrading from version 0.7.0 to 0.8.0</title></properties><body><section name="Upgrading from 0.7.0 to 0.8.0"><p>
|
||||
The following should help most casual users of the project update their
|
||||
applications:
|
||||
|
||||
|
@ -13,34 +7,35 @@ applications:
|
|||
|
||||
<li>HttpSessionIntegrationFilter has been removed. Use net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter instead.
|
||||
Note you will need to set the mandatory "context" property to something like "net.sf.acegisecurity.context.security.SecureContextImpl".
|
||||
It's not the default because we want no dependencies between the context package and the rest of Acegi Security.<br><br></li>
|
||||
It's not the default because we want no dependencies between the context package and the rest of Acegi Security.<br></br><br></br></li>
|
||||
|
||||
<li>Filter ordering has changed. See the reference guide for confirmation of the correct ordering. Basically you should have
|
||||
HttpSessionContextIntegrationFilter appear before any of your authentication mechanisms.<br><br></li>
|
||||
HttpSessionContextIntegrationFilter appear before any of your authentication mechanisms.<br></br><br></br></li>
|
||||
|
||||
<li>IoC container hosted filter chains can now be used instead of lengthy web.xml declarations. See the reference guide or the
|
||||
Contacts Sample for further information.<br><br></li>
|
||||
Contacts Sample for further information.<br></br><br></br></li>
|
||||
|
||||
<li>Certain classes have been moved to new packages: ContextHolderAwareRequestWrapper (and its filter),
|
||||
AuthenticationSimpleHttpInvokerRequestExecutor, ContextPropagatingRemoteInvocation,
|
||||
SecureContext (and its implementation). These classes were moved as part of refactorings aimed at
|
||||
improving the simplicity of the project's design.<br><br></li>
|
||||
improving the simplicity of the project's design.<br></br><br></br></li>
|
||||
|
||||
<li>If you wish to use the new ConcurrentSessionController you must declare the HttpSessionEventPublisher context listener in your
|
||||
web.xml<br><br></li>
|
||||
web.xml<br></br><br></br></li>
|
||||
|
||||
<li>The JaasAuthenticationCallbackHandler interface has had it's setAuthentication method removed.
|
||||
The handle method now takes both the Callback and Authentication objects as arguments.<br><br></li>
|
||||
The handle method now takes both the Callback and Authentication objects as arguments.<br></br><br></br></li>
|
||||
|
||||
<li>Added AuthenticationException to the AutenticationEntryPoint.commence method signature.<br><br></li>
|
||||
<li>Added AuthenticationException to the AutenticationEntryPoint.commence method signature.<br></br><br></br></li>
|
||||
|
||||
<li>Added AccessDeniedException to the SecurityEncorcementFilter.sendAccessDeniedError method signature.<br><br></li>
|
||||
<li>Added AccessDeniedException to the SecurityEncorcementFilter.sendAccessDeniedError method signature.<br></br><br></br></li>
|
||||
|
||||
<li>The Authentication.getDetails() no longer returns simply the IP address used for authentication.
|
||||
It now returns a WebAuthenticationDetails instance, which contains the IP address, session information,
|
||||
and can be extended to store further details.<br><br></li>
|
||||
and can be extended to store further details.<br></br><br></br></li>
|
||||
|
||||
</ul>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
</p></section></body></document>
|
|
@ -1,11 +1,5 @@
|
|||
<html>
|
||||
<head>
|
||||
<title>Acegi Security - Upgrading from version 0.8.0 to 0.9.0</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Upgrading from 0.8.0 to 0.9.0</h1>
|
||||
|
||||
<p>
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<document><properties><title>Acegi Security - Upgrading from version 0.8.0 to 0.9.0</title></properties><body><section name="Upgrading from 0.8.0 to 0.9.0"><p>
|
||||
The following should help most casual users of the project update their
|
||||
applications:
|
||||
|
||||
|
@ -22,79 +16,80 @@ applications:
|
|||
SecurityContextHolder</a> and provides a single getter/setter for a
|
||||
<a href="../multiproject/acegi-security/xref/net/sf/acegisecurity/context/SecurityContextHolder.html">SecurityContext</a>.
|
||||
<code>SecurityContextHolder</code> guarantees to never return a <code>null</code> <code>SecurityContext</code>.
|
||||
<code>SecurityContext</code> provides single getter/setter for <code>Authentication</code>.<BR><BR>
|
||||
<code>SecurityContext</code> provides single getter/setter for <code>Authentication</code>.<br></br><br></br>
|
||||
|
||||
To migrate, simply modify all your code that previously worked with <code>ContextHolder</code>,
|
||||
<code>SecureContext</code> and <code>Context</code> to directly call <code>SecurityContextHolder</code>
|
||||
and work with the <code>SecurityContext</code> (instead of the now removed <code>Context</code>
|
||||
and <code>SecureContext</code> interfaces).<br><br>
|
||||
and <code>SecureContext</code> interfaces).<br></br><br></br>
|
||||
|
||||
For example, change:<br>
|
||||
For example, change:<br></br>
|
||||
<code>
|
||||
SecureContext ctx = SecureContextUtils.getSecureContext();<br>
|
||||
SecureContext ctx = SecureContextUtils.getSecureContext();<br></br>
|
||||
</code>
|
||||
to:<br>
|
||||
to:<br></br>
|
||||
<code>
|
||||
SecurityContext ctx = SecurityContextHolder.getContext();<br>
|
||||
SecurityContext ctx = SecurityContextHolder.getContext();<br></br>
|
||||
</code>
|
||||
<br>
|
||||
and change:<br>
|
||||
<br></br>
|
||||
and change:<br></br>
|
||||
<code>
|
||||
<bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter"><br>
|
||||
<property name="context"><value>net.sf.acegisecurity.context.security.SecureContextImpl</value></property><br>
|
||||
</bean><br>
|
||||
<bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter"><br></br>
|
||||
<property name="context"><value>net.sf.acegisecurity.context.security.SecureContextImpl</value></property><br></br>
|
||||
</bean><br></br>
|
||||
</code>
|
||||
to:<br>
|
||||
to:<br></br>
|
||||
<code>
|
||||
<bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter"><br>
|
||||
<property name="context"><value>net.sf.acegisecurity.context.SecurityContextImpl</value></property><br>
|
||||
</bean><br>
|
||||
<bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter"><br></br>
|
||||
<property name="context"><value>net.sf.acegisecurity.context.SecurityContextImpl</value></property><br></br>
|
||||
</bean><br></br>
|
||||
</code>
|
||||
<br>
|
||||
<br></br>
|
||||
|
||||
We apologise for the inconvenience, but on a more positive note this means you receive strict
|
||||
type checking, you no longer need to mess around with casting to and from <code>Context</code>
|
||||
implementations, your applications no longer need to perform checking of <code>null</code> and
|
||||
unexpected <code>Context</code> implementation types.<br><br></li>
|
||||
unexpected <code>Context</code> implementation types.<br></br><br></br></li>
|
||||
|
||||
<li><code>AbstractProcessingFilter</code> has changed its getter/setter approach used for customised
|
||||
authentication exception directions. See the <a href="../multiproject/acegi-security/xref/net/sf/acegisecurity/ui/AbstractProcessingFilter.html">
|
||||
<code>AbstractProcessingFilter</code> JavaDocs</a> to learn more.<br><br></li>
|
||||
<code>AbstractProcessingFilter</code> JavaDocs</a> to learn more.<br></br><br></br></li>
|
||||
|
||||
<li><code>AnonymousProcessingFilter</code> now has a <code>removeAfterRequest</code> property, which defaults to <code>true</code>. This
|
||||
will cause the anonymous authentication token to be set to null at the end of each request, thus
|
||||
avoiding the expense of creating a <code>HttpSession</code> in <code>HttpSessionContextIntegrationFilter</code>. You may
|
||||
set this property to false if you would like the anoymous authentication token to be preserved,
|
||||
which would be an unusual requirement.<br><br></li>
|
||||
which would be an unusual requirement.<br></br><br></br></li>
|
||||
|
||||
<li>Event publishing has been refactored. New event classes have been added, and the location of
|
||||
<code>LoggerListener</code> has changed. See the <code>net.sf.acegisecurity.event package</code>.<BR>
|
||||
<br>
|
||||
For example, change:<br>
|
||||
<code>LoggerListener</code> has changed. See the <code>net.sf.acegisecurity.event package</code>.<br></br>
|
||||
<br></br>
|
||||
For example, change:<br></br>
|
||||
<code>
|
||||
<bean id="loggerListener" class="net.sf.acegisecurity.providers.dao.event.LoggerListener"/><br>
|
||||
<bean id="loggerListener" class="net.sf.acegisecurity.providers.dao.event.LoggerListener"/><br></br>
|
||||
</code>
|
||||
to:<br>
|
||||
to:<br></br>
|
||||
<code>
|
||||
<bean id="loggerListener" class="net.sf.acegisecurity.event.authentication.LoggerListener"/>
|
||||
</code><br><br>
|
||||
<bean id="loggerListener" class="net.sf.acegisecurity.event.authentication.LoggerListener"/>
|
||||
</code><br></br><br></br>
|
||||
</li>
|
||||
|
||||
<li>Users of the <code><authz:authentication></code> JSP tag will generally need to set the <code>operation</code>
|
||||
property equal to "username", as reflection is now used to retrieve the property displayed.<br><br></li>
|
||||
<li>Users of the <code><authz:authentication></code> JSP tag will generally need to set the <code>operation</code>
|
||||
property equal to "username", as reflection is now used to retrieve the property displayed.<br></br><br></br></li>
|
||||
|
||||
<li>
|
||||
Users of <code>net.sf.acegisecurity.wrapper.ContextHolderAwareRequestFilter</code> should note that it has been
|
||||
renamed to <code>net.sf.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter</code>.<br><br>
|
||||
renamed to <code>net.sf.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter</code>.<br></br><br></br>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The concurrent session support handling has changed. Please refer to the Reference Guide to
|
||||
review the new configuration requirements.<br><br>
|
||||
review the new configuration requirements.<br></br><br></br>
|
||||
</li>
|
||||
|
||||
|
||||
</ul>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
</p></section></body></document>
|
|
@ -1,22 +1,8 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
|
||||
<head>
|
||||
<title>Acegi Security - Upgrading from version 0.8.0 to 1.0.0</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Upgrading from 0.9.0 to 1.0.0</h1>
|
||||
|
||||
<p>
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<document><properties><title>Acegi Security - Upgrading from version 0.8.0 to 1.0.0</title></properties><body><section name="Upgrading from 0.9.0 to 1.0.0"><p>
|
||||
The following should help most casual users of the project update their
|
||||
applications:
|
||||
</p>
|
||||
|
||||
<h1>Changes 0.9.0 to RC1</h1>
|
||||
|
||||
<ul>
|
||||
</p></section><section name="Changes 0.9.0 to RC1"><ul>
|
||||
|
||||
<li>The top level package name has changed. Simply find "net.sf.acegisecurity" and replace with
|
||||
"org.acegisecurity".</li>
|
||||
|
@ -46,13 +32,7 @@ you localise this file to another language, please consider attaching it to a
|
|||
<a href="http://opensource2.atlassian.com/projects/spring/secure/BrowseProject.jspa?id=10040">new JIRA task</a>
|
||||
so that we can include it in future Acegi Security releases.</li>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
<h1>Changes RC1 to RC2</h1>
|
||||
|
||||
|
||||
<ul>
|
||||
</ul></section><section name="Changes RC1 to RC2"><ul>
|
||||
|
||||
<li>
|
||||
org.acegisecurity.ui.rememberme.RememberMeProcessingFilter now requires an authenticationManager property. This will generally
|
||||
|
@ -86,13 +66,7 @@ method internally stores null, which helps avoids redeployment issue caused by t
|
|||
approaches (see SEC-159 for further details).
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
<h1>Changes RC2 to Final</h1>
|
||||
|
||||
|
||||
<ul>
|
||||
</ul></section><section name="Changes RC2 to Final"><ul>
|
||||
|
||||
<li>
|
||||
AbstractProcessingFilter.onUnsuccessfulAuthentication(HttpServletRequest, HttpServletResponse)
|
||||
|
@ -115,7 +89,4 @@ instance. The LdapAuthoritiesPopulator interface and its default implementation
|
|||
LdapUserDetails. Any customized versions should be updated to use the new method signatures.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
</ul></section></body></document>
|
Loading…
Reference in New Issue