Re: MySQL communication around a firewall
Nigel Wade wrote:
The normal solution to this problem is to use a servlet acting as a proxy. Your
web client talks to the servlet, the servlet in turn talks to the database. The
servlet is behind the firewall so should be ok connecting to the database. The
database authentication is done there, by the servlet, protected by the
firewall. The servlet controls what actions the client can perform on the
database.
If the servlet is deployed to the same server that the web client downloads from
so much the better as the web client won't need to be signed.
This is an example of a very powerful pattern I learned as the "resource
manager" paradigm. I don't know the formal pattern name, if there is one, but
the idea is that a shared or otherwise vital resource sits behind a manager,
also called a dispatcher, a controller or a driver. There may be many worker
tasks or threads or components within the resource itself, but the central
manager collects all requests and is in charge of dispatching all work to the
resource, and conversely responsible for collecting the resource's response
and replying with it to the requester.
The database engine itself is such a resource manager, where the data store
itself is the resource. Nigel's solution brings that out one more layer: the
entire DBMS, engine included, is a resource from the point of view of the web
application. The dispatch servlet becomes the resource manager, concerned not
only with the data /per se/ but with security and authorization. Adding that
layer of indirection protects the data store from inconsistent or malicious
actions.
Note that resource managers need not necessarily be singletons. The data
access servlet can have multiple concurrent instances, possibly distributed
about a server farm, for complete scalability with no conflict with its
purpose: to manage authorized access to the data resource.
--
Lew