Here is an interesting approach to solving an issue with exposing DB connections via a Type 3 Driver to an un-trusted client: DUALITY JDBC Proxy - Server controlled JDBC connections and executions. The Server actually opens connection to the client - no need to open firewall:
http://www.linus.no/jdbcproxy.html And more on controlling the SQL operations: "The DUALITY Server examines all SQL statements. Statements may be permitted or denied based on regular expressions you define. The DUALITY Server also introduces named SQL statements. This feature enables a security scheme where only predefined SQL statements are permitted - the client application will not contain the actual statement. " Oleg Proudnikov [EMAIL PROTECTED] ----- Original Message ----- From: "David Wood" <[EMAIL PROTECTED]> To: "hibernate-devel" <[EMAIL PROTECTED]> Sent: Monday, June 14, 2004 10:10 AM Subject: Re: [Hibernate] New subproject proposal: a batching, client/server JDBC layer > I just did a swing client that uses hibernate, and although in my case I > was alright to make the database available to the client hosts, I'm sure > many can't. So it sounds like this will certainly be useful, but it has me > thinking: will this layer be added only because nobody trusts the > database's security ("I can't expose my DB to the world because someone > will get in")? Or perhaps because the DB's security model is "too general" > and therefore too difficult for people to secure properly ("I can't safely > make a 'restricted' user because I'll accidently - or necessarily - leave > it with dangerous privileges")? > > Of course, whether directly or through a JDBC wrapper, a user can always > extract the security privileges from a client and circumvent any > restrictions imposed by that application; read any row or send a few > "delete from..." So I can see an argument for something more fine-grained > or custom wrapping the database to ensure that it really behaves like a > proper "server application" and only expected operations are allowed, > security policy is enforced, etc. It's not clear how that works with > Hibernate... by using stored procedures somehow? Or, perhaps, Hibernate > really lives on the server after all, and the whole client works via > RMI/SOAP etc and is "thinner." > > I am used to people treating their DB like a windows box, hiding it behind > firewalls, etc. I certainly see the sense in it. And this is really not > practical, but in theory at least, wouldn't it be better to fix the > database (whichever one it is) rather than wrapping it, if we trust it > this little? Or is it impossible to safely expose the database at all, > through a wrapper or not? > > [EMAIL PROTECTED] wrote on 06/14/2004 08:44:23 > AM: > > > I've been thinking about the problem of users who ask for > > "lazy fetching from the client". As we keep explaining, > > this is an incredibly bad idea, since transaction > > demarcation and caching (and probably also dirty checking) > > should take place in the same tier as lazy fetching. > > > > However, many of these users are writing Swing or rich client > > applications and I think perhaps the reason they ask for this > > is that they are forced to run Hibernate in the server tier > > since they are not allowed to open a JDBC connection from the > > client, and Hibernate is tied to the JDBC connection pool. > > > > After thinking about this, I think I've decided that there is > > nothing at all wrong with doing data access via a remote > > "gateway", so that Hibernate would run in the client tier and > > act as a remote client of a server-side JDBC connection pool. > > This would enable transaction demarcation, caching, dirty > > checking and lazy fetching to be done on the client, but the > > actual database access would take place on the server. > > > > Now, as far as I can see, there is no reason at all for this > > to be implemented as part of the ORM solution. Indeed, it > > makes much more sense for this to be simply wrapper abound > > JDBC. The wrapper would do transparent batching of > > INSERT/UPDATE/DELETEs and provide pluggable client/server > > remotability strategies (RMI/SOAP/etc), delegating to > > a server-side connection pool. It could even be used outside > > of Hibernate. > > > > Does anyone know of an existing project like this? If not, > > should we start one, under the aegis of hibernate.org? Is > > anyone interested in starting work on this. I'm convinced > > it is not at all difficult to implement. > > > > Have I gone insane? > > > > -- > > Gavin King > > +61 41 053 4454 > > +1 404 822 8349 > > > > Hibernate > > [EMAIL PROTECTED] > > http://hibernate.org > > > > JBoss Inc > > [EMAIL PROTECTED] > > http://jboss.com > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the new InstallShield X. > > From Windows to Linux, servers to mobile, InstallShield X is the > > one installation-authoring solution that does it all. Learn more and > > evaluate today! http://www.installshield.com/Dev2Dev/0504 > > _______________________________________________ > > hibernate-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > From Windows to Linux, servers to mobile, InstallShield X is the > one installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > hibernate-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
