|
|
There are some substantial differences between the architecture in a 5250 environment and the architecture in a web environment. These differences affect the tasks a developer must go through when developing a web application.
This document describes these differences and gives advice on what to remember when developing web applications.
In a 5250 application a job is started for each session initiated by an user. Furthermore, the 5250 client and the server job will be connected during the lifetime of the session. This means that all information related to the user and the session can be stored in variables or memory because these are only accessible by the active job for the session.
In a web application environment the browser (client) and the web application (server) will only be connected during the lifetime of one request! This means that the web application must first identify the user session from the request and then load the session data that is needed to process the request.
The WebsydianExpress runtime handles this by storing a session ID with each event, meaning that the session ID will be part of the request that is sent to the web application when the user activates an event. The web developer can then use this session ID to store information related to the session or the user associated with the session.
The session ID is fetched using the API GetSessionID.
For performance reasons the web application consists of a fixed number of pre-started jobs. When a request is received by the web server, the request is then handled by one of these jobs. This means that the same job over time will process requests from many different sessions, and that requests from the same session will be handled by different web application jobs. The consequence of this is that it is not safe to store session information in program variables for use in a later request.
So to summarize the following important guidelines must be kept in mind when developing a web application:
When a user enters an input value in a 5250 panel the panel puts restrictions to what the user can enter. E.g. when the panel has defined a 3-digit numeric field as input field on the panel, then the user is only allowed to enter a 3-digit numeric value.
The browser does not enforce any of these kind of restrictions. Furthermore, when web input and parameters are sent from the browser to the web application they are sent as alphanumeric data. This means that when the web application expects a numeric value it is up to the developer to first move the web input value into a numeric variable, and then make sure that the numeric value is within the legal range.
When doing this it is important to remember proper error handling as it is not guaranteed that the user has entered a numeric value.
So it is important to validate all web input for the following:
Please refer to the example business processes for examples on validation.
As mentioned above it is not possible to store data for later requests in memory or program variables. The alternative is to store this in a database file keyed by the session ID.
However, there are some cases where this is not an option and where the application must store information with the event that is to be used by the program handling the event. E.g. when presenting the user of a list of invoices to select, then the key of each invoice record will be stored with the select event in the HTML page. The key will then be sent as part of the request when the user selects an invoice, and the web application will then know which invoice has been selected.
As the invoice key is stored in the page this raises another problem, because the HTML page can be saved from the browser and then modified by the user. In this example it means that the user then can change the invoice key and then get access to see other users' invoices.
To protect against this all information used by the program that is handling the event and must not be modified by the user should be stored as secure parameters.
Secure parameters are stored with the event in the HTML page, along with a signature based on all the secure parameters.
When the secure parameters and the signature is read by the program handling the event, then the signature is re-calculated from the values read and compared with the read signature. If there is a mismatch between the two signatures, then some of the parameters have been changed by the user and the program should abort further processing on the event.
The secure parameters are handled using the following APIs: SetParm, SetGridParm, GetParm, ValidateParm.
Please refer to the Order Catalog application for an example on using secure parameters.
More information on security can be found in Security.
Online documentation - WebsydianExpress v3.5