Ben Alex wrote:
With the benefit of hindsight, I would have stored the SecureContext. It's just a question of how to handle the backwards compatibility, and whether it's a good idea to break when there is an alternative for the minority of users who are customising their SecureContext.
I can understand the problem of backwards compatibility very well. But the intermediate solution of storing two variables should be easy and effective. The old variable could be deprecated now and removed many versions later (if at all). It would also be possible to introduce a second class hierarchy for IntegrationFilters that store the Context rather than the Authentication (with subclasses only for containers/methods that actually work with the strategy).
Being rather short on time, I will now just write a Filter on my own. It's just a matter of several lines of code, as I can leave out a lot of special cases that I don't need.
I am surprised that you call the SecureContext customizing users a minority. Where do you usually store your "user" business object? Or do you retrieve it from the DAO on each request?
Best regards,
Andreas
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
