William Worth wrote:
> On Fri, 29 Oct 1999, you wrote:
> > William Worth wrote:
> >
> > > How would you suggest using your servlet to access a database then ?
> > > TCP/IP sockets (interprocess comms) are not serializeable either...
> > >
> >
> > The most common solution is to store a connection pool in the ServletContext
> > attributes, or in a static variable. Besides the serializability issue,
> > connection pools let you share a given number of JDBC connections between a
> > much larger pool of actual users, instead of having a connection per user
> > needed when you store connections in the session.
> >
> > By the way, the reason for the "Serializable only" restriction is so you can
> > run your servlets in a servlet container that supports distributed
> > operations. The 2.2 API specification (released after Jason's book) clarified
> > this requirement to only apply when you set the <distributable/> flag in your
> > web application deployment descriptor. Otherwise, it doesn't matter.
> >
> > Craig McClanahan
>
> Thanks. Would I be correct in thinking that connection pools create potential
> security problems if not all users are accessing the same db, and / or some
> have more privileges than others ? - or can this all be handled relatively
> simply be 'grading connecitons' ?
> William.> >
>
I've seen two different approaches to this issue at the connection pool level:
* Use a connection pool that knows about more than one username/password
combination, and gives you the correct one. This is practical if there are only
a few sets of privileges, so you can still share connections.
* If you have a database that supports roles, like Oracle, and your database
permissions are based on roles rather than users, you can do a SET ROLE
command in the connection pool to set the right access privileges for the
requesting user as it returns each connection.
In the long term, the direction I see happening is that authentication and access
control are being defined at the application server level, rather than the database
level. That's certainly true if you use EJBs, and the servlet 2.2 deployment
descriptor demonstrates the same philosophy. This isn't going to help you much,
though, if your database security is based on individual database usernames --
that's not going to be a scalable approach in the long run, because it still needs
connection-per-user.
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
