Oh :)
I was entirely under the impression that this was a webapp :) Tomcat
will not do anything to help you. You *have* to keep the connection
data on the client app... there's just no getting around it. If you
were to serve it out of an LDAP store, you'd still need to secure that
LDAP store with a password that the client has.
Not sure what your database is, but Oracle (for example) has support
for named user authentication, where you log in with a generic JDBC
login and then bind each connection to a specific user for permissions
control. This is more geared toward web apps where you'd need to
control permissions, but the connections are assigned out of a pool,
but in your case, this sort of two-phase authentication would allow
you to double-secure access with the user's username/password, which
would not be "hardcoded" in the app.
So, back to the point - you do have to hardcode the password
somewhere, but there are tons of techniques out there for cloaking it.
You can combine those with a custom Cayenne Configuration
(http://objectstyle.org/confluence/display/CAYDOC/Customizing+Configuration).
Nonetheless, providing direct database access to non-trusted users is
a highly suspect practice. Even if the password were secured, its an
open TCP connection that a clever user could easily hijack. Even
easier than that, they could just unpackage the JAR, subclass
something, and do whatever they want.
There is still value to JNDI (though now you're back to the LDAP-esque
realm), because JNDI can provide access to the database connection via
some sort of stepped authentication like a key exchange, but that is a
lot of work and still only of questionable security. I just don't see
you being able to get the security that you want if you're going
direct to the DB, unless you can take advantage of the Oracle feature
I described above. That's the whole point of a service layer in
between, like WS or Cayenne OPP ;)
Cris
On 2/20/06, Tomi NA <hefes..mail.com> wrote:
>
>
> On 2/20/06, Cris Daniluk <cris.danilu..mail.com> wrote:
> > > I'd say I probably covered the tomcat configuration part. However,
> cayenne
> > > modeler's stairing me in the face and wants to know the new data node
> JNDI
> > > Location. I'm quite certain a part of what I should write here is
> jdbc/zs2,
> > > but I'm equaly certain that I should somehow let cayenne know which
> tomcat
> > > instance I'm referening to (= tomcat IP:port).
> > >
> > Cayenne runs inside the Tomcat, so it already knows IP/port :)
> >
> > "jdbc/zs2" should be the only name you need...
> >
> > By the way, you may want to use a Context based resource and not a
> > global one, if you ever indend to deploy two versions of your app to
> > the server (for testing, etc), or just to avoid confusion in general.
>
>
> Wow wow wow, this can't be right: we must be talking about different
> problems.
> I'm talking about a client/server application based on a rich client (i.e.
> swing), using tomcat on the server as a JNDI DataSource server. What you're
> telling me would make sense for a web app (where cayenne indeed would run on
> the same server), but that's not the issue.
> So, how do the rich clients (using cayenne under the hood, running on client
> machines, obviously) know where to look for a JNDI DataSource?
>
> t.n.a.
>
This archive was generated by hypermail 2.0.0 : Mon Feb 20 2006 - 14:12:50 EST