SPI Programming Manual (G06.24+, H06.03+, J06.03+)

General SPI Programming Guidelines
SPI Programming Manual—427506-006
5-41
Defining the Context Token
As described in Section 2, SPI Concepts and Protocol, the requester should return this
context token in the next command message along with the original command.
Each server that receives a command with a context token should check for:
•
The command and parameters are consistent with the context supplied.
•
The requester has not bypassed security or integrity constraints by supplying a
forged or modified context token.
As an example of the latter case, consider an application that sends a command to
start a number of terminals, some of which it is not permitted to start. The context
token in this case needs to include a name or identifying number for the next terminal
on which the command is to be performed. When the server attempts to start a
terminal that the application is not permitted to start—say, TERM3—it might return an
error list indicating a security error and a context token indicating that the next terminal
to start is TERM4. The application might then attempt to circumvent this restriction by
changing the terminal name in the context token from TERM4 to TERM3. To prevent
such a breach of security, the server should apply security checks on each new
command.
Another example of the latter case is an ALTER LIKE command (to alter the
characteristics of an object to be the same as those of another object named in the
command) implemented so that the set of values being altered is carried in the context
token. In this situation, the server should protect the integrity of the context by checking
these values for validity each time the context token is returned in a new command.
Figure 5-1
illustrates the exchange of messages for a command requesting information
about all terminals in an application (INFO TERM *):