The following is that Fang Xu Dilla has some problems with the company's current J2EE development, I hope everyone will mention their own opinions.
Specifically, 5 points below: 1. About J2EE security Considerations The safety of the company's current procedures is the control method of database and program code, and individuals feel that there is the following drawbacks: a. Program complicated, Maintenance difficulties Because all security control and implementation of all security in the current program are code
The database is required, so it is necessary to write a large number of code such as the authentication of the user's legitimacy, user rights control, etc. It is necessary to use the code to manually implement, and all this needs to be manually maintained. If the demand has Changes should also change a large number of programs, such as updating all code with this related JSP page when the button permission code is changed. B. Not easy to control on the page is not available to the URL access (because the current code) The page only verifies the session without verifying the permissions to access the page user), and because the button control is currently adopted from the database acquisition ID and uses JS judgment, the information on the current page is not safe, the user can pass the page source The way the code has a URL address that implements the function page, and the user can pass the security control on the program on the address bar. And because the page is sent to the customer and JS is also running on the client, it is not at all This method of presenting page encryption is also impossible to achieve true encryption, so if the client encryption is used, it is not advisable .c. Portgrade is not strong because of the current code control security, and now popular LDAP control mode Not compatible, if the standard LDAP is used in the future, you need to change the permissions control code, which is not strong. If the J2EE comes with security control, it can be easily solved. J2EE security adopts The user (user), group, role (Role) is combined to control program security. J2ee uses a domain (Realm Indicates a database with complete users, roles, and packet information) to control everything. In WebSphere Only a class of a USERREGISTRY interface is required to be implemented in the development, and the database is read in. And in the specific program development (any program item on this server) does not have to use any code. To achieve security control, only the security policy needs to be configured, and the remaining implementations are implemented by the J2EE container. Due to the way of configuring security policies, there is no specific program code, the development and maintenance or future demand changes Just configure or change security policies and configuration files without writing or changing program code. So you can solve the problem that the problem of "complicated, maintenance difficulties" is good to control through J2EE security policies. User permissions of a page, using role (Role) control, you can specify what role to allow any role to allow for any role (GET, POST ...) to access. Therefore, you can control the URL, solve the user's address bar Enter the URL directly to jump out of the program control. As for the control of the page information, you can also use the servlet's standard API to get the user role to control whether the button is output, not using J in the page. S is judged whether or not the page is displayed or encrypted. The most fundamental solution is to see that the user can see is the information that the user can see, and the user cannot output it to the user instead of encrypting it. As for the graft, because the LDAP itself is part of J2EE security. The J2EE container in WebSphere provides user custom authentication (database belonging to this), local OS verification, and LDAP verification. So if you use standard LDAP or other When the way the user security is controlled, the code or security policy does not have any changes at all, and it can be perfectly transitioned to any kind of authentication. There is no transplantability. 2. Discussion on the display layer is currently displayed Most of the development of OCX is an OCX. The advantage of using OCX is that the development is simple, but there are some shortcomings A. Need safety signature: Because Microsoft's security control of OCX is strict, especially the current WinXP SP2 pair OCX security Sexual control is more stringent, and there is no CA signature OCX at the system default configuration. If you change the client's configuration, the amount is large, even if you use the program to unify the client configuration to allow installation, there will be problems, because If you change the client's configuration, it greatly reduces the security of the client, and the modified client will not distinguish between our OCX is an OCX with viruses on the network., The modified client Like someone left a back door .b. Compatibility question: OCX has a compatible problem, OCX developed under Windows 2000 may not be good to run in WinXP, and it may not be able to run in XP 2000 Next (main reason is different, there are differences in the mechanism), and there is a variety of mechanisms. Now there is a wide variety of operating systems, so there is a problem in compatibility, which can be considered in the display layer to implement, the following is Several UI (User Interface) development technology A.applet:
Similar to OCX mechanism, compatibility and security have strong OCX, and because of the Java mechanism, it can be convenient to background interaction (using RMI and other technologies), but the development is more difficult, and every time you run Loading, the speed is slow, and there must be supported by the client to install JRE, but different from the OCX, JRE support can adopt the program unified installation because the applet does not have a security problem. B.JS XMLHTTP: I Personally, the performance technology of the recommended display layer, which is completely established in HTML, there is no security and compatibility problem, and it is not difficult to develop, JS itself is also the development script of class objects, which can be very convenient control page display And there are currently many excellent Open Source JavaScript libs to support development. For example, ActiveWidgets is a good one. He has encapsulated multiple JS objects, including XMLHTTP, and takes this object, which can be easily. The data is converted to the table. It can be easily transmitted in the background with the page with the XMLHTTP object. It can easily convert the data to HTML display in the client side. And the CSS can be easily implemented. Personality customization, etc. (this is also an OCX is more difficult to implement) of course the defects of this technology, because the way to use scripts can not completely reach the OCX and Applet Swing.c.flex: is also a fashionable manifestation Using Flash RemoteObject Remote call server-side programs, use XML as transport form, which is the advantage of being separated from HTML to use flash XML, and it can be easily implemented in Flash, and Flash on the network also provides a variety of controls. Support, it uses ActionScript to control. But because of its unfamiliar with Flash, it is not possible to develop, and now we are working hard to study the technology. Personally think that this technology is a very good way. D.XUL, XAML , XWT: These three methods are similar to techniques and GUI control libraries that describe the GUI layout in XML. Also from the HTML as the previously mentioned Flash, where XUL is proposed by Mozilla, XAML is the next generation of Web technology proposed by Microsoft. XWT is an open source project. Xul's operation requires mozilla support, XAML requires Microsoft support, Microsoft The support for this technology will be added by default in the next operating system. And XWT is a complete cross-platform (IE, Mozilla, Opera; Windows, Linux, Solaris), which will not be tied to a platform like Xaml or XUL. On, and it is very small, the performance is also very good. XWT has two versions, which are run as an ActiveX control, while in all Java browsers (IE, Mozilla, Opera) can be run as an applet. Because IE comes with JVM does not support Swing, XWT does not use Swing. XWT communicates with the server via XML-RPC or SOAP to obtain data that needs to be displayed, so you can use any technologies that support XML-RPC or SOAP to do server-end development. XWT is running inside a strict sandbox without having to worry about it will perform illegal operations. Its ActiveX version is written in Java, and is compiled as a local code with GCJ, and can be accessed through the COM interface. JavaScript is used as its scripting language. But Flex, XUL, XAML, XWT these four are not the B / S structure, but the C / S structure communication with HTTP, and is the thin client C / Structure, it is a technology that abandoned HTML, abandoning B / S, although I have affirmed that the final outlet of the Web representation is to completely abandon the clumsy-based HTML FORM request / response mode, XML technology and The WebService system architecture is thoroughly transformed into the core.
