The DWR security mechanism of DWR advanced topics __dwr

The DWR security mechanism of DWR advanced topics
----------
Many other Ajax tools do not take security into account and allow you to confront security threats. DWR provides some security mechanisms, and you may find it perfectly suited to your needs. DWR uses multi-tier security methods, however, at least one mechanism must always be enabled.

1. Default Reject
Without making any settings, DWR automatically adopts the "Default Reject" method. This means that, by default, DWR does not allow any classes to be accessed remotely. Recall that each class that you want remote access must add a <create> element to the configuration file. This <create> element should also be nested within the <allow> element. By adding this information entry, you can tell DWR that the remote invocation of the specified class is authorized. However, if you do not add the appropriate information entry to this profile, the remote call is blocked.

Readers will surely realize that there is actually a potential security flaw in this approach: By default, all methods of the authorized class can be accessed by remote tuning. In general, that's OK, because our usual code-organizing habit is that a class always contains all the "safe" methods that can be invoked remotely. In fact, we can also design this way, some of the methods in the class can be safely invoked remotely, and some methods do not allow remote invocation. As an example, we do not want to invoke the divide () method remotely. We can simply add a <exclude> element. Now, there is a child element <include> element of a <exclude> element and a <create> element. These two elements are mutually exclusive, that is, you can use the <include> element to specify a list of methods that can be invoked remotely (methods that are not listed are not remotely invoked), or use the <exclude> element to specify a list of methods that are not allowed to be invoked remotely ( Any methods that are not listed are accessible.

<?xml version= "1.0" encoding= "UTF-8"?> <!
DOCTYPE dwr public   
    "-//getahead limited//dtd Direct Web Remoting 3.0//en" "Http://getahead.org/dwr/dwr30.dtd" >< c2/><dwr>
    <allow>
        <create creator= "new" javascript= "Mathdelegate" >
            <param name= " Class "Value=" app. Mathdelegate "/>
            <exclude method=" divide "/>
        </create>
    </allow>
</dwr>

Both <include> and <exclude> elements receive a comma-separated list as the property value of method, so that you can specify as many methods as you want. Note that DWR never allows its own internal classes to be accessed remotely, thereby reducing the likelihood that an attacker can compromise the internal mechanism of DWR and further enhance the security of the application.

2. Java EE Security and DWR
If you are committed to further enhancing the security of your Web application, you can take other steps to integrate Java EE Security and DWR. With this capability, you can specify that only a specific security role can access a specific remote class, or a specific method for a particular role to access a remote object.
2.1 Protection Dwrservlet
The first thing to note is that the security mechanism based on the role of Java EE is used to ensure the security of Dwrservlet. To achieve this, we must introduce additional configuration options: multiple Dwr.xml files. By default, DWR looks for a file named Dwr.xml in the Web application's Web-inf directory, so no further modifications are necessary. However, if you want to place this profile elsewhere, you need to add an init parameter to the servlet, similar to the following:

<init-param>
    <param-name>config</param-name>
    <param-value>configfiles/ Dwrconfig.xml</param-value>
</init-param>

DWR now loads the file Dwrconfig.xml in the Configfiles directory (relative to the Web application's root directory).
Another handy trick is that you can specify more than one configuration file. To do this, you only need to add more than one init parameter, the format of the parameter name is CONFIGXXXX, where xxxx can be any content. The name of each init parameter must be different, and the purpose of using XXXX is only to ensure uniqueness. For example:

<servlet>
    <servlet-name>dwr-invoker</servlet-name>
    <servlet-class> uk.ltd.getahead.dwr.dwrservlet</servlet-class>
    <init-param>
        <param-name>config1234 </param-name>
        <param-value>configFiles/dwrConfig1234.xml</param-value>
    </ init-param>
    <init-param>
        <param-name>config5678</param-name>
        <param-value >configFiles/dwrConfig5678.xml</param-value>
    </init-param>
</servlet>

Dwr loads all of the configuration files and merges these profiles into one master configuration (no other configuration is required.) )
How to integrate these into the security aspect. What you also need to do is define multiple instances of dwrservlet, such as the example:

<servlet> <servlet-name>dwr-user-invoker</servlet-name> <servlet-class> Uk.ltd.getahead.dwr.dwrservlet</servlet-class> <init-param> <param-name>config-user</para m-name> <param-value>WEB-INF/dwr-user.xml</param-value> </init-param> </servlet> &L T;servlet> <servlet-name>dwr-admin-invoker</servlet-name> <servlet-class> Uk.ltd.getahead.dwr.dwrservlet</servlet-class> <init-param> <param-name>config-admin</par
am-name> <param-value>WEB-INF/dwr-admin.xml</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>dwr-admin-invoker</servlet-name> <url-pattern>/dwradmin/ *</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>dwr-user-invoker</
Servlet-name> <url-pattern>/dwruser/*</url-pattern></servlet-mapping> 

There are actually two types of users: general users and management users. Each type of user has a different profile, and more importantly, each type of user makes a different URL mapping. This is important because you can make full use of the Java EE Security mechanism to protect sevlet based on roles. For example:

<security-constraint>
    <web-resource-collection>
        <web-resource-name> dwr-admin-collection</web-resource-name>
        <url-pattern>/dwradmin/*</url-pattern>
    < /web-resource-collection>
    <auth-constraint>
        <role-name>admin</role-name>
    < /auth-constraint>
</security-constraint>
<security-constraint>
    < web-resource-collection>
        <web-resource-name>dwr-user-collection</web-resource-name>
        <url-pattern>/dwruser/*</url-pattern>
    </web-resource-collection>
    < auth-constraint>
        <role-name>user</role-name>
    </auth-constraint>
</ Security-constraint>

Now, only administrative users can access the classes defined by the Dwr-admin.xml file and access them through the/dwradmin/* URL pattern. Similarly, a generic user can access only the classes defined in the Dwr-user.xml file and be accessed through the/dwruser/* URL pattern. This allows you to effectively protect objects that allow remote access with the help of a standard container management security mechanism.
2.2 Protection of individual methods
You can also protect the individual methods in the specified remote accessible class. You only need to define the role in the Web.xml file and the DWR configuration file, while in the DWR configuration file you need to add a <auth> element to the <create> element of the class that you want to protect. Here is the sample code:

<create creator= "new" javascript= "Remotableclass" >
    <param Name= "class" value= " Com.myapp.RemotableClass "/>
    <auth method=" Delete "role=" admin "/>
</create>

Now, we declare that the delete () method of the Remotableclass class can only be invoked by the administrative user. Note that all other methods are not protected accordingly, because this is the default behavior of DWR. With this subtle control, you can more flexibly apply container management security and design classes that you want to access remotely.