> I want the Wicket support to be ultra-basic If you make it to basic people won't have the flexibility they need. And you get what johan is describing, people working around our security system and building there own. Besides we can (not saying we should) make it utra complex and still provide an additional layer on top of it to abstract most of it away, giving you and people who only need the basics just that but at the same time allowing power users to use the lower level. For the record I am against making an ultra complex solution but I'm all for providing a solution that has more then just basic support. If I want basic support I'll use checkaccess. I think the solution johan and I came up with is quite elegant and simple enough to understand yet powerfull enough to support all but the most crazy adaptations. Not saying it doesn't need more work, but I do think we are on to something here.
BTW did you notice the 3 of us are the only ones bickering about this :) Kindda makes you wonder if there is a need for security out there at all :) Maurice -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eelco Hillenius Sent: woensdag 26 oktober 2005 23:47 To: wicket-develop@lists.sourceforge.net Subject: Re: [Wicket-develop] integrating authorization I forgot about our plans of writing out OGNL. So, I guess all models that are provided by wicket can work, and the 'clean' use of the interface (using setObject) can work too. That's about it though, as we still can't shield from code doing User u = (User)getModelObject(); u.setName("got you there!"); About building in security: you're hitting the spot! That's exactly why I want the Wicket support to be ultra-basic. Thing is that there is no support for it at all right now. I'd like to have the same level of support as we have for ajax now: it's basic, but flexible and understandable, and people will do it their own way anyway. Eelco On 10/26/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > readonly models are simple we already have it working > And access based on model data is one of the big things i want to have > supported! > if not then i personally say don't add anything lets build on top of wicket > what you need. > > Because anything that doesn't give me the possiblitly to do the steps i > want is useless > i know it and i have seen it so often in a current project. We have build > in security but > it misses this or that and what happens? 7 out of 10 persons are building > there own complete security. > So if we have such a basic support that most persons are still completely > do it them selfs > then i don't want it anyway. > > I agree that enums or bits are not the the best things but what can we do? > We just have different things to test > if a special implemenation don't want to support it its fine. They can > ignore it ofcourse (and return true or false > depending on yes/now or what ever) > > I just want finer gradiant support. > > For exampe what do you mean with it will be hard for property models? > Property models are not the things you want to test. > Data testing you do on the real object. So most of the time the object that > is in the compound model of the form > > For example Person that is of Type X can be seen by a user that is of Type > Y or is only readable by a user of Type Z. > > That where the things that was shown and was supported by the acegi > framework in the session i saw. > with ofcourse links that where visible or not depending of the user/roles. > All with really horrible configuration so that is ofcourse something i want > to avoid :) > > > > On 10/26/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > A couple of more 'new insights' ;) > > > > * having a read-only option is good. Still don't agree with the > > enumeration though. Jonathan came up with another reason why you don't > > want to have an enumeration. If there's any more things we come up > > with in the future (which would, in the case of an enumeration mean > > adding a new enumeration value), you would have a silent addition > > instead of an API break. We think that is bad, as you want to force > > clients how to support such new functionality. Having seperate > > (boolean returning) methods does that. Again, any implementation is > > free to map these seperate methods into one enumeration based method. > > > > We can't guarantee read-only models. Sure, we can proxy any IModel > > object, but that would only work for very simple models. All models > > that work like property models for instance can't be guaranteed unless > > we would make full copies of the model objects and wrap those, which > > would be way too expensive. Furthermore, as there are many ways to > > secure you domain objects (like not providing public setters, or e.g. > > using the new Hibernate functionality in case you use that framework), > > I think we shouldn't even try to do this in Wicket. It will otherwise > > confuse people/ make Wicket harder to understand, and we can't even > > guarantee anything but the simplest use cases. > > > > Eelco > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. > > Get Certified Today * Register for a JBoss Training Course > > Free Certification Exam for All Training Attendees Through End of 2005 > > Visit http://www.jboss.com/services/certification for > more information > > _______________________________________________ > > Wicket-develop mailing list > > Wicket-develop@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
