# 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"/>
  `