Hi Remy, we also discussed the possibility of creating connection pools. In this case we also found scenarios where it seems to make sense to have userid and password in the store e.g. in the case you would like to allow dynamic instanceation of connection pools. But however, this would also not confirm to the original design you described below. What do you suggest how we can come to a solution? Do you think it would be better to pass just the CredentialsToken instead of passing the SlideToken to the store?
regards Eckehard -----Original Message----- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Friday, March 01, 2002 4:38 PM To: Slide Developers Mailing List Subject: Re: cvs commit: jakarta-slide/src/share/org/apache/slide/store AbstractStore.java > Hi Remy, > > that's exactly what we try to do. We try to marriage the webdav > authorisation with the authorisation of a database (as far as it is > possible). The reason is, we would like to allow that the last decision if a > specific user get rights on data stored in the database should be by the > database administrator and not by the webdav adminitrator (if the two roles > are played by different persons). I think this should not be the normal way > to restrict the user rights, but it should be possible for the database > administrator to remove the rights of one specific user without closing the > whole account of the webdav server. Additional to this we are doing the > authentication against this database as well. So just users knowen by the > database are authenticated. I understand that in the real world admins would want to also set connection passwords, but the original design was to handle DB auth about the same way a connection pool does it. So I would specify the auth using static parameters. Also, this feature is useless for many stores except the JDBC store (for ex, in the J2EE store, the pool is initialized somewhere else, so that authentication method can't be used consistently). Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
