Yes, I think you're right. Apparently, depending on the requirements of
the project, the client may as well either run Hibernate and speak
directly with the database, or (if you're concerned about security and
have the time) that both JDBC and Hibernate must be on the server. Clients
should generally follow the latter design - certainly if they are exposed
to the world. But I can imagine in many cases the former shortcut may be
necessary or even appropriate...
Gavin King <[EMAIL PROTECTED]> wrote on 06/14/2004 10:33:24 AM:
> OK, so the problem is that this JDBC proxy still allows arbitrary SQL to
> be executed on the server. Never worked with rich client applications
> before, I had not realized that this (security) was the main reason for
> choosing to add a third tier. I thought the problem was minimizing
database
> connections for license/scalability purposes.
>
> I guess this argument against doing it at the JDBC level also applies
> to doing it at the ORM level, since it still opens up the possibility of
> arbitrary queries.
>
>
> David Wood wrote:
>
> >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?
> >
> >
>
>
> --
> 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
