> >> * The SecureRegistry doesn't completely encapsulate the Registry > >> > >> Right now the user has to construct a Registry and pass it to the > >> SecureRegistry. The problem here is, there is insecure access to the > >> same registry since the use build that externally. If we aggregate the > >> Registry in to the SecureRegistry, an instance of a SecureRegistry is > >> always secure. > > No I don't agree. This was a deliberate design. The code that > instantiates the real registry (new JDBCRegistry) does of course have > full access to the internal registry. But that is life. If I have the > uid/pw of the database then I have full access to the database, I can > mess it up as much as I like. > > The point of having the SecureRegistry take a registry as a parameter is > to completely isolate the security from the main registry code - AND the > registry from the security code. Think of it in terms of Aspect Oriented > Programming. > > The security in real life comes from the fact that the WebApp ALWAYS > uses the SecureRegistry interface. > > Paul >
This comments is based on some design best practices (design by constrain). It is always good to design/code things in a way that developers get compilations errors not run time errors or some times bugs. If some one want to do some thing malicious they will some how find a back door. Since every one seems to be OK with what we currently have, I don't think I should make it an issue at this point. :-) BTW, how about the class names I have proposed? >> >> BTW, I was thinking about Paul's reason to have a JDBCRegistry class and a >> InMemory Registry class where he would like the developer to know what >> exactly they are going to get just looking at the class name (without >> reading the Javadoc). In that case how about naming them >> as, "PersistentRegistry" and "TransientRegistry"? >> /Sanjaya _______________________________________________ Registry-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
