For client/server systems, users cannot freely change the control of the application on the client side. For Internet/Intranet applications using Web Browsers, however, the user can easily change the Web Browser's condition, so it may depend on this operation as to whether the consistency of the Web application on the server functions properly.
Generally, problems may be caused by the following operations:
When the Refresh button of the Web Browser is used.
This button can re-execute the processing that has already executed, so a conflict may occur in an application, such as during registering or updating.
When the Submit button (with "SUBMIT" specified in the INPUT tag INPUT attribute) is pressed twice or more times by the user, sending the same transactional request to the Web Server.
Pressing this button twice or more times causes the same processing to be executed again and again, so a conflict may occur in the application, such as during registering or updating.
When processing is started in the middle of an application by directly inputting the bookmark or URL.
An application can be executed without authorization, so a problem regarding security may be caused. In addition, the application is not executed in the correct sequence, so a logic problem may occur.
When a cached page is referred to.
Using the cache function of a Web Browser, the requested Web page can be referred to without accessing the server (it is held in cache on the client machine), so the user may refer to secret information contained along with the Web page in the cache, for example: the sales data and personal information.
The following illustrates examples of measures to take against the above noted potential problems, which can be taken by Web Browsers or Web applications on the server.
User's operation | Examples of measures | |
|---|---|---|
Web Browsers | Web applications | |
Use the Refresh button of the Web Browser. | Using JavaScript, open the window without the Return button. | Keep track of the application execution sequence, and confirm that the application is correctly executed. |
Press the Submit button twice or more times. | Using JavaScript, determine whether the application is half-processed. If the application is half-processed, disable the Submit button. | Design Web applications not to cause a problem even when the same processing is executed twice or more times. |
Start the processing in the middle of a business by directly inputting the bookmark or URL. | Using JavaScript, open the window without a bookmark. | Keep track of the application execution sequence, and confirm that the application is correctly executed. |
Refer to the cached page. | Invalidate the cache of the Web Browser. | Keep track of the application execution sequence, and confirm that the application is correctly executed. |
Generally, the measures to take depend on the content of an application. For example, the cache may not need to be invalidated for applications with low security requirements. If another operational problem is caused by the content of the application, take the measures against the problem from its own aspect.
