Francois Orsini wrote: > I think we just *cannot* let anyone override the 'defaultConnectionMode' > database configuration property - The user would have had to be granted > a 'system privilege' of some sort. Now as far as migrating a secure > database to a legacy mode one, there would need to be good reasons for > that, such as running an embedded application with no need for a secure > database mode. But then if we allow migration of secure mode to legacy, > might as well keep the property scheme as you have originally defined it > and no new connection url property. > > --francois > > On 1/8/06, *Satheesh Bandaram* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > We could use 'defaultConnectionMode' property to store secureMode > like you said, but .. > > 1. What would happen if a user tries to set the value to > 'fullAccess' or 'readOnlyAccess' in a secure database? Should > we catch the case and raise an error since otherwise the > database would switch to being a legacy database. > 2. While I am not promising migration from secure database to > legacy database, overloading this property will make the value > being lost if someone adds logic to provide this migration > later and if someone tries to do a roundtrip of a database > from legacy mode... > > Satheesh > > > Francois Orsini wrote: > >> Sounds good. >> >> Where would you persist the secureMode value? >> >> I guess it would then be ok to consider 'defaultConnectionMode' to >> be legacy only unless you are thinking of still using it to store >> secureMode value? Could you clarify please. >> >> --francois >> >> On 1/6/06, *Satheesh Bandaram* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> I have been thinking if use of properties is the right way to >> chose sqlStandard security mode or legacy mode... Properties >> are meant to be more dynamic in nature and since I don't yet >> plan to allow switching between SqlStandard mode (with support >> for Grant and Revoke) to legacy mode. >> >> I think use of URL property to indicate which security mode is >> wanted during a database create time is more natural. If one >> wishes to create a database with support for Grant and Revoke, >> it could be specified by a URL attribute like secureMode. >> >> ij> connect 'jdbc:derby:securedb;create=true;*secureMode=true*'; >> >> If secureMode is not specified, current default of legacy mode >> database without grant/revoke capability would be created in >> 10.2 release. If secureMode is true, a database with support >> for grant/revoke statements is created. In this database, >> property value of 'defaultConnectionMode' is a no-op.
I'm still thinking about this 'secureMode' approach and the interaction with the existing authentication model. One issue I do have is the name of the attribute, 'secureMode'. I don't believe that the current grant/revoke syntax makes Derby completely secure, thus this attribute may mislead people. Note sure I have a better name though. :-( Dan.
