On 3/15/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
On 3/15/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > This totally stinks for now but you're right it's the only way currently. I > could expose an API to just request a context without authentication however > this would allow stored procedures in the server to do that as well and > assume any user. Yeah, I kind of knew that. Really, the only way to restrict access intra-VM is to get into the whole code permissions thing.
Exactly. We're going to have to re-evaluate everything to do that correctly. Incidentally, this is handled nicely in the OSGi service platform.
People have different ideas of what OSGi is; perhaps modular bundles, jar metadata, etc., but when it comes down to it, it is a comprehensive framework. Like any good framework, written by experienced developers, you find yourself needing certain functionality that it already has a story for. In this case, we could use bundle permissions to restrict access between, for example, an LDAP protocol provider bundle and a core DIT bundle.
Yeah this is certainly a big benefit that we'll be able to get along with JMX for free. Hopefully.
SPs will use JNDI too to work on the server while emebedded in it via the > server side JNDI (core context factory) provider. We need to figure out > something better but for you SASL effort this may not happen in time. We > should use this workaround for now and consider revamping this design issue > sometime later in the 1.5 branch. > > WDYT? Yeah, too big to fix right now. I'll use simple authentication internally; have to add that to the beans for each of the protocol providers. Today they rely on the JNDI env parameters being set in the server.xml, which makes it hard to start them programmatically, again the use case is embedding or integration tests.
Yeah I like using beans instead of using env properties. Get's crazy fast when dealing with them. This way we'll have good typing and qualification within the bean. Alex
