> I'm starting to use/evaluate acegisecurity for some project, > and here are my impressions so far on the cfg complexity.
Welcome! :-) > I'm not sure I understand for what is "Run-As Authentication > Replacement", and why I need it in my cfg. > If not defined it throws: > java.lang.IllegalArgumentException: A RunAsManager is required > at > net.sf.acegisecurity.intercept.AbstractSecurityInterceptor.aft > erPropertiesSet(AbstractSecurityInterceptor.java:179) > > It seems to me that for what I'm trying to do at the moment, > I don't need it, so I see 2 options: > 1) It's not crucial cfg element, and should not be required. It really isn't crucial, unlike the other collaborators used by AbstractSecurityInterceptor. I'm happy to add null detection so RunAsManager-related code is skipped if the property is null. Does anyone have any concerns with this? > 2) It's something that is necessary no matter how simple > authentication/authorization one is trying to implement. > And so this maybe should be internally set for some > default, and if latter one feels the need to provide some > customized version, be able to do so by setting the adequate property. Loading a default RunAsManagerImpl would be a bit tricky, as it needs to share the same key with RunAsImplAuthenticationProvider. That isn't impossible, but would result in more configuration complexity than leaving as the current two separate beans. Instead, it's safer to not define a RunAsManager default at all, meaning any RUN_AS_* configuration attribute a user may have defined in their application context will not be validated and thus a configuration error will be detected during afterPropertiesSet(). > This is in my opinion, how things are done in Spring, and > one of its major and unique advantage. > Not exposing non-crucial cfg elements is the answer for > keeping cfg complexity at the lowest possible level. I would like to simplify configuration by wiring up the context. But in fairness, if you count the number of lines of XML in the samples/quick-start and then the number of lines needed in the "traditional" web.xml PLUS some-servlet-container-auth-config.xml file, it's reasonably comparable despite delivering much more flexibility and functionality. > I took a peek at RunAsManagerImpl.java and the only thing > it checks for in afterPropertiesSet is if the key is filled. > Can't this be checked in some other way, to avoid need of > lifecycle handling (InitializingBean) and so avoid the need > to have it defined in the context? The key is a mandatory property so created authentication tokens are acceptable to the RunAsImplAuthenticationProvider. > I also agree that having a lot of filters in web.xml is not > quite attractive, and would prefer to have only one. I agree, although we need to ensure the filters can still be setup manually in web.xml, as people might have particular needs to chain a custom filter in between Acegi Security filters. For example, I need to do this at present to support a Jakarta Slide integration so Acegi Security can provide it authentication information. I'll add a consolidated filter to my to-do list (unless someone beats me to it). > At this time, I haven't still looked very deeply into the > code, so quite probably I don't understand all issues > involved, and how to resolve them. > I'm just reporting you my first impressions. > Hope it will help in some way. Thanks. I appreciate your feedback. I hope you find Acegi Security useful in your project. Best regards Ben ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
