I think we can safely assume that there will always be a security service registered. If there isn't one, Jetspeed throws exceptions during aggregation and portlets all produce content with exceptions. I know, I recently tried this. In the security_14 branch, I just checked in a 'nosecurity' implementation of authorization (access controller). It always returns true for all permission checks. Please give it a try when you get a chance. I hope to finish the security branch by this weekend. At that point, I would like to merge it to main with everyone's approval of course...
Anyway, IMO, I don't really see the need for the code below (SecurityServiceRegistered) > -----Original Message----- > From: Santiago Gala [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 14, 2002 3:48 AM > To: Jetspeed Developers List > Subject: BaseProfileLocator SecurityServiceRegistered question > > > I wonder which is the intention of this code: > > if (SecurityServiceRegistered()) > this.setUser( JetspeedSecurity.getAnonymousUser() ); > else > { > // warning: this ties us to turbine security > // we could load class from TRP > // (services.SecurityService.user.class) > User user = new BaseJetspeedUser(); > user.setUserName("anon"); > this.setUser(user); > } > > In particular, I imagine two things: > > - It could be oriented to prevent errors during initialization > - It could be oriented to run Jetspeed without Turbine > Security in place > (i.e. for an Anonymous unprotected Portal) > > Can anybody bring some light here? Google does not find > "SecurityServiceRegistered". Can I apply for a prize? :-) > > Regards, > Santiago > > > -- > To unsubscribe, e-mail: > <mailto:jetspeed-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
