JDBC专题介绍（4）

JDBC专题介绍（4）

4. 2. Application

　　 Java也可以用来建立普通的应用，从而想一般的应用一样在客户机上使用。我们相信随着开发工具越来越多，人们开始认识到提高程序生产效率的必要性，以及Java的其他优点，Java的这种用法将越来越流行。在这种方式里面，Java的代码是可以信赖的，且被允许读写文件打开网络连接等等，就想其他的应用程序代码一样。

　　 也许这些Java应用使用的最多的是在一个公司内部或者在Intr.net上，所以不妨成为Intranet场合。例如一个公司希望利用Java及其GUI构件工具来建立他的基于合作数据模式的合作软件。这些应用程序将存取局域网或者广域网的数据。Java应用可以作到这些。

　　 Java应用程序场合和Intranet场合与applet场合有诸多不同。例如标定一个数据库最自然的方式是用一个数据库的名字，就象"Customers" 和"Personnel"这样。然后用户希望系统能够定位具体的机器，DBMS，JDBC driver，和Java应用程序。

4. 3. 其他场合

还有其他一些有趣的场合：

1). 已验证的applet（Trusted applets）是指那些已经被Java虚拟机器认定是可以信赖的applet。他们之所以被认为是可信的是因为他们已经对上了特定的密匙，或者用户认为从特定来源来的applet是可信的。在安全的方面上他们与应用（appliction）相同，但是其他方面（例如定位一个数据库）与则与applet相似。

2). 与直接从Java GUI出发用客户/服务器模式来度曲DBMS服务器不同，三层存取方式可能被使用。在这个场合里面，Java应用程序对中间层的服务发出调用，中间层的服务在网上，它又再去调用数据库。这些调用可能通过RPC (remote procedure call)或者ORB (object request broker )。在这两种场合里面，中间层最好使用一个对象变化。我们希望三层结构会变得越来越普遍，因为对于MIS管理者来说，这可以使得他们有机会在公共数据库上显式地定义合法操作等。同时三层结构可以提供许多效率上的好处。

　　 目前中间层一般用C或者C++这样的语言来完成。通过优化编译器把把Java 字节代码翻译成为高效的机器代码，中间层也可以用Java来实现。Java有许多优良特性（健壮性，安全性，多线程）可以达到中间层需要达到的目的。



5. 安全性考虑

　　 作为网络上的语言JAVA必须十分注安全性的考虑。基于上面的讨论，JDBC的两种主要使用场合里面，我们必须考虑安全性问题：

* 在Java applications的场合里面Java代码是本地的，所以也是"trusted"

* 没有验证的Java applet代码不可以存取本地的以及其他网络的数据。

5. 1. JDBC 和未验证的applet

JDBC首先必须符合JAVA的一般安全规则。另外：

* JDBC 必须认为没有验证的applets是不可靠的。

* JDBC 不可以让不可靠的applets存取本地数据库。

* 一个已经向JDBC DriverManager注册的是JDBC Driver只能存取它所来的数据源。

* 一个applet也只能向它所Download来的服务器来存取数据。

　　 如果JDBC驱动层如果完全确信对一个数据库服务器打开连接不会引起认证或者权限问题（可能由网上随机主机上运行的程序引起），那么它就允许applet打开这样的连接。数据库服务器不通过IP地址来限制存取是相当少的，主要是为了举例。（当心，这一段话我可能翻译反了！！！大家看看原文。）这些限制是相当烦琐的。不过他们与对一般applet的限制是一致的我们没有必要放开这些限制。

5. 2. JDBC 和Java应用程序

　　 对于一个普通的Java应用程序（例如全部用Java代码而不是不可靠的applet ）JDBC将从本地的类路径里面获得驱动，并且允许应用程序自由存取文件，远程服务器等等。

　　 但是和applet一样，如果由于某些原因一个没有验证的sun.sql.Driver类从远程的来源里面获得，那么这个驱动只能和相同地方来的代码配合。

（未完待续）

5. 3. Driver的安全责任

　　 JDBC driver可能在各种情况下使用，所以驱动的编制者遵循一定的简单的安全规则，从而避免applet做非法的数据库连接。

　　 如果所有的驱动都象applet一样从网上下载，那么这些原则将是不必要的，因为普通的安全规则已经对它做了限制。但是驱动的编写者必须记住一旦他们的驱动获得成功，用户将在本地磁盘安装这些驱动，那么驱动将成为Java环境中一个被信任的部分，所以必须确信它不会被来访的applet所滥用。所以我们鼓励所有的驱动编写者必须遵循一定安全原则。

　　 所有这些原则都是在连接打开的时候使用。这正式驱动和虚拟机器检查当前调用者是否真的可以与指定的数据库连接的时刻。一旦连接建立就不必做更多的检查了。

5. 3. 1. 分享TCP/IP连接的时候必须谨慎 　　如果一个JDBC驱动试图打开一个 TCP 连接，那么这个打开会被Java 安全管理机制自动检查。这个机构会检查当前调用栈里面有没有applet，如果有那么就限定它可以访问的机器集合。所以一般地JDBC驱动可以把TCP建立检查留给Java虚拟机。

　　 但是如果一个JDBC驱动试图在多个数据库连接之间共享一个TCP连接，那么驱动就必须自己负责检查每个调用者是否真的被允许与目标数据库联系。例如如果我们为applet A打开了一个通往机器foobah 的TCP连接，这并不意味着applet B被自动允许来共享这个连接。applet B可能没有任何访问机器foobah的权力。所以在允许某个程序重用一个现成的TCP连接之前，JDBC 驱动必须通过安全机构来检查当前的的调用者是否可以访问这个连接。通过下面的代码可是实现这个功能。

SecurityManager security = System.getSecurityManager();

if (security != null)

{

security.checkConnect(hostName, portNumber);

}

　　 如果连接是不允许的，那么Security.checkConnect方法将产生一个java.lang.SecurityException。 5. 3. 2. 检查所有的本地文件访问

　　 如果一个JDBC取得需要访问本地机器上的数据，那么他必须确信调用者是被允许打开这个文件的。例如：

SecurityManager security = System.getSecurityManager();

if (security != null)

{

security.checkRead(fileName);

}

　　 如果对特定文件的访问是不允许的，那么Security.checkRead方法将产生一个java.lang.SecurityException。

5. 3. 3. 作好最坏的准备

　　 一些驱动可能使用本地的方法来桥接底层数据库程序。则这些情况里面判断那些本地文件将被底层函数所访问是困难的。

　　 在这些环境里面用户必须作好最坏的打算，并且否决所有下载applet所发出的数据库存取，除非驱动可能完全确信将要做存取是没有问题的。

　　 例如一个JDBC-ODBC桥接器必须检查ODBC数据源的的名称，确保applet只可以访问它的"生源地"。如果对有的名字中不能判断出数据源的主机名，那么只能否决这个访问。

　　 为了决定一个当前的调用者是可以信赖的应用还是一个applet，JDBC驱动必须能够检查这个调用者是否可以写一个随机的文件：

SecurityManager security = System.getSecurityManager();

if (security != null)

{

security.checkWrite("foobaz");

I. }

□摘自日月光华站(bbs.fudan.edu.cn)
在保留http://www.javajia.com原出处的情况下，欢迎转载!

（全文完）

原文转自：http://www.ltesting.net