William Becker wrote: > I'm happy to do the release. I'm writing up a release procedure in the > wiki, if you have any input to it, that would be great, so we are sure > we don't miss any steps. > > I am pretty sure it is stable. I have been using the constructors for > a while and haven't had any issues with them. I'll do a RC first > (which I doubt many people will use anyway!) and if we get no > complaints on that for a week, we can make it official. > > Cheers, > Will > > On Wed, Apr 2, 2008 at 12:36 PM, Arthur Blake <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > I'm neutral on the issue. If you do the release this time around > I'm all for it :) > I'd like to add a demo of jabsorb using the ExtJS framework and > maybe get it into this release. > Since you added most of the new features in 1.3, how stable do you > think it is? > Are the changes extensive enough that an RC build is warranted? > > > On Tue, Apr 1, 2008 at 8:53 PM, William Becker <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Re: issue34, > > It *should* be ok, so long as the user cannot access the calls > of JSONRPCBridge from javascript. I don't think this is > possible so it ought to be ok. If you are serious about > security however, I would avoid releasing any system classes > out in the wild, just to be double careful. > > Given that we agree on this, pending input from Michael, > should we go and release 1.3 some time soon? >
Do you think we have adequately addressed the security issues? I'm not completely aware of how the constructor feature is used. Can I call any arbitrary constructor or is it only for registered classes? If it is only registered classes then I'm happy - it is up to the user to only export classes or instances where they have thought of the associated security issues i.e. library users can of course make insecure apps with the present version by exporting insecure classes or instances - as with any web service framework - it can't address the issue of the user exporting interfaces to insecure code. Michael. _______________________________________________ Jabsorb-dev mailing list [email protected] http://lists.jabsorb.org/mailman/listinfo/jabsorb-dev
