upgrade-090-100.html 5.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  3. <html xmlns="http://www.w3.org/1999/xhtml">
  4. <head>
  5. <title>Acegi Security - Upgrading from version 0.8.0 to 1.0.0</title>
  6. </head>
  7. <body>
  8. <h1>Upgrading from 0.9.0 to 1.0.0</h1>
  9. <p>
  10. The following should help most casual users of the project update their
  11. applications:
  12. </p>
  13. <h1>Changes 0.9.0 to RC1</h1>
  14. <ul>
  15. <li>The top level package name has changed. Simply find "net.sf.acegisecurity" and replace with
  16. "org.acegisecurity".</li>
  17. <li>
  18. DaoAuthenticationProvider has a property, authenticationDao. This property should now be renamed to
  19. userDetailsService.
  20. </li>
  21. <li>
  22. In JSPs, each "authz" taglib prefix must be changed from uri="http://acegisecurity.sf.net/authz"
  23. to uri="http://acegisecurity.org/authz".
  24. </li>
  25. <li>net.sf.acegisecurity.providers.dao.AuthenticationDao is now org.acegisecurity.userdetails.UserDetailsService.
  26. The interface signature has not changed. Similarly, User and UserDetails have moved into the latter's package as well.
  27. If you've implemented your own AuthenticationDao, you'll need to change the class it's implementing and quite likely
  28. the import packages for User and UserDetails. In addition, if using JdbcDaoImpl or InMemoryDaoImpl please
  29. note they have moved to this new package.</li>
  30. <li>Acegi Security is now localised. In net.sf.acegisecurity you will find a messages.properties. It is
  31. suggested to register this in your application context, perhaps using ReloadableResourceBundleMessageSource.
  32. If you do not do this, the default messages included in the source code will be used so this change is
  33. not critical. The Spring LocaleContextHolder class is used to determine the locale of messages included in
  34. exceptions. At present only the default messages.properties is included (which is in English). If
  35. you localise this file to another language, please consider attaching it to a
  36. <a href="http://opensource2.atlassian.com/projects/spring/secure/BrowseProject.jspa?id=10040">new JIRA task</a>
  37. so that we can include it in future Acegi Security releases.</li>
  38. </ul>
  39. <h1>Changes RC1 to RC2</h1>
  40. <ul>
  41. <li>
  42. org.acegisecurity.ui.rememberme.RememberMeProcessingFilter now requires an authenticationManager property. This will generally
  43. point to an implementation of org.acegisecurity.providers.ProviderManager.
  44. </li>
  45. <li>
  46. org.acegisecurity.intercept.web.AuthenticationEntryPoint has moved to a new location,
  47. org.acegisecurity.ui.AuthenticationEntryPoint.
  48. </li>
  49. <li>
  50. org.acegisecurity.intercept.web.SecurityEnforcementFilter has moved to a new location and name,
  51. org.acegisecurity.ui.ExceptionTranslationFilter. In addition, the "filterSecurityInterceptor"
  52. property on the old SecurityEnforcementFilter class has been removed. This is because
  53. SecurityEnforcementFilter will no longer delegate to FilterSecurityInterceptor as it has in the
  54. past. Because this delegation feature has been removed (see SEC-144 for a background as to why),
  55. please add a new filter definition for FilterSecurityInterceptor to the end of your
  56. FilterChainProxy. Generally you'll also rename the old SecurityEnforcementFilter entry in your
  57. FilterChainProxy to ExceptionTranslationFilter, more accurately reflecting its purpose.
  58. If you are not using FilterChainProxy (although we recommend that you do), you will need to add
  59. an additional filter entry to web.xml and use FilterToBeanProxy to access the FilterSecurityInterceptor.
  60. </li>
  61. <li>
  62. If you are directly using SecurityContextHolder.setContext(SecurityContext) - which is not
  63. very common - please not that best practise is now to call SecurityContextHolder.clearContext()
  64. if you wish to erase the contents of the SecurityContextHolder. Previously code such as
  65. SecurityContextHolder.setContext(new SecurityContextImpl()) would have been used. The revised
  66. method internally stores null, which helps avoids redeployment issue caused by the previous
  67. approaches (see SEC-159 for further details).
  68. </li>
  69. </ul>
  70. <h1>Changes RC2 to Final</h1>
  71. <ul>
  72. <li>
  73. AbstractProcessingFilter.onUnsuccessfulAuthentication(HttpServletRequest, HttpServletResponse)
  74. has changed it signature (SEC-238). If subclassing, please override the new signature.
  75. </li>
  76. <li>
  77. ExceptionTranslationFilter no longer provides a sendAccessDenied() method. Use the
  78. new AccessDeniedHandler instead if custom handling is required.
  79. </li>
  80. <li>
  81. There have been some changes to the LDAP provider APIs to allow for future improvements, as detailed in
  82. <a href="http://opensource.atlassian.com/projects/spring/browse/SEC-264">SEC-264</a>. These
  83. should only affect users who have written their own extensions to the provider. The general LDAP
  84. classes are now in the packages org.acegisecurity.ldap and the org.acegisecurity.userdetails.ldap
  85. package has been introduced. The search and authentication classes now return an
  86. <a href="../multiproject/acegi-security/apidocs/org/acegisecurity/userdetails/ldap/LdapUserDetails.html">LdapUserDetails</a>
  87. instance. The LdapAuthoritiesPopulator interface and its default implementation now both make use of
  88. LdapUserDetails. Any customized versions should be updated to use the new method signatures.
  89. </li>
  90. </ul>
  91. </body>
  92. </html>