4. Token Processing.pdf

1. Welcome to “Token Processing in T24” learning unit. This learning unit will teach you the working of tokens in T24. Tokens are used in T24 to uniquely identify a request coming from a user.

BR3.Token Processing-R10.01

1

After completing this learning unit/course, you will be able to: •Describe Tokens in T24 •Explain the need and working of Tokens in T24 •Explain the files F.OS.TOKEN and F.OS.TOKEN.USE


2

What does the term token mean in the English language? A token is a unique number used to uniquely identify different facts or requests. For example, if you go to a bank to withdraw cash from your savings bank account, you might have to fill in a withdrawal slip with all the details and give it in the counter. In return, the bank will give you a unique number to identify your request. The teller in the bank will process your request and deliver cash based on this unique number. This unique number is known as token. So similarly, since T24 is a request-response based system, any requests coming into T24 is given a token to differentiate between the other requests coming in from different users.


3

1. When a user signs on to T24 via browser, a request to create a session is sent to the T24 server. This will always be the first request from the user to T24. Will this request have a token? No 2. The T24 Browser component on the App Server is the one that identifies and distinguishes a sign on request from other requests. 3. When a sign on request reaches the T24 server, a routine named OFS.SESSION.MANAGER (called from jbase_agent) picks up the request, understands that it is a sign on request, does SMS validations and if successful creates a new token for that user. This is the token that will be used by the user when he sends his subsequent request. Please note that the token is not created for the sign on request from the user but for the subsequent request. The token once created, is stored in the database. It is vital to understand that it is T24 that is creating and storing the tokens. Token number is appended to the response and sent to the app server 4.At the app server layer, the response is separated from the token and the token is retained for the next request from this user. The response is now sent to the user and the T24 screen opens. From R09 , only one token will be allotted per user. Each request or response will then use the same token for the complete length of the user’s session.


4

1.After the user is successfully signed on, the next request would be to either open a record or just to list or anything else. For your better understanding, assume that the user opens a record in any application in T24 2.As long as the current session is active, T24 will use the same token for all concurrent requests sent by this user. 3.The request reaches T24 with this token. T24 will now check if the token is valid. If valid, processes the request and generates a response. 4.When the app server receives the response, it will separate the token number from the response. The same token will be attached to the next request and this cycle continues till the user signs off from T24. The application screen requested is what the user sees as his response to the request. Hence for all the subsequent requests from this user the same token will be used.


5

1. When the user signs off from T24, this is also a request. 2. The T24 Browser identifies that this is a sign off request, appends the token it has to the request and sends it to T24 for processing. 3,4. T24 understands that the request is a sign off request, checks if the token is valid and if found valid, processes the request and generates a response. T24 will now delete the token and sends the response back. The user is signed off from T24 in response to his request.


6

1.What happens if the user signs on to T24 from another session via Browser while he is still signed onto his first Browser session? 2.The T24 Browser identifies that this is a sign on request 3.SMS validations are performed and if successful, previously used token of his older session are deleted and new token is created and stored in the database. T24 appends and sends response with new token number. So, in other words irrespective of the number of sessions a user can open, tokens are maintained for only one session. A user cannot have multiple tokens. 4.At the app server layer, response and the token number are separated. Response is sent back to the user and T24 screen opens. Note that the previously logged in session of the user will result in ‘Security Violation’ when any action is preformed from that session.


7

F.OS.TOKEN and F.OS.TOKEN.USE are the two files that are used to store token related information in T24. In order to understand the working of these files in sufficient detail, how and when they are populated are shown with the help of screen shots. Before any user sign’s on, these two files are empty.


8

In the example, the user AUTHORISER has signed in. Once the sign on request has been processed successfully, the files F.OS.TOKEN and F.OS.TOKEN.USE are updated. Take a look at the content of F.OS.TOKEN and F.OS.TOKEN.USE files. How do these files get values? What could be the logic behind having two files for tokens?


9

The OFS.SESSION.MANAGER routine called from the jbase_agent, creates token and stores them in F.OS.TOKEN. The token generated here is what is sent back with the sign on request’s response for a particular user. Now what if there are multiple users logged on to the system at one point in time? How many records are created in this file? When multiple users log in at the same time, there will be one token created in F.OS.TOKEN for each user. Therefore at one point in time, this file can hold multiple records. The ID of the record is the token number. Token numbers are generated using a core T24 routine named ALLOCATE.UNIQUE.TIME. This routine creates a 12 digit number UUUUUTTTTT.NN where UUUUU stands for user number, TTTTT stands for time in seconds since midnight and NN stands for sequence number for the requests generated within the same second. This is used to identify the requests uniquely. The contents of the record is The first line in the record holds the User name The second line shows the status which is ONLINE Third holds the COMPANY ID to which the user has logged on to Fourth holds the time in seconds Fifth line holds the machine current date in internal machine format


10

When the user AUTHORISER sends a sign on request from Browser, T24 generated a token number 152200001535387.03 and sends back the response. This token number is written onto F.OS.TOKEN. This file always holds the token generated for the user. For every request from this user, this token will be used. There is one more file which gets updated for tokens. The file F.OS.TOKEN.USE is also updated with token related information. The ID of the record in this file will be the user name and the record content will be the token number generated.

11

The requests sent to T24 can be viewed if you start the jbase agent in the debug mode using the following command , jbase_agent –p -L2. Port number will be configured in t24-ds.xml. The screen shot shows the log for the sign on request. The request type ‘CREATE.SESSION’ indicates that it is a sign on request. This indicator is the one that signals T24 that this request will not come with a token number. Once a response was received by the Jboss app server, the T24 Browser in the Jboss app server understands that the response has to display the initial T24 screen to the user.


12

Let us take a look at what is logged when the user types CUSTOMER in the command line and hits enter. The same token number 152200001535387.03 in the F.OS.TOKEN file is used to process the request. Note that the routine OS.NEW.DEAL is executed to process the request. The response ‘XML.DEAL’ to open the CUSTOMER application will be sent back to the user with the same token.


13

Now if you check the contents of F.OS.TOKEN and F.OS.TOKEN.USE it will still hold the same token number.


14

When the user tries to log off from T24, the response ‘XML.LOGOFF’ goes back to the user. Also note that the message displayed on the window after logoff is also stored in the log file. When the user logs off, all related records in F.OS.TOKEN and F.OS.TOKEN.USE gets deleted. If the user does not sign off but closes the window, on a subsequent sign on by the user, the old records in F.OS.TOKEN and F.OS.TOKEN.USE relating to the user gets deleted and new tokens are allotted.


15

1. If a user is inactive for a certain period of time, any subsequent action by the user results in a Security Violation message like ‘We have not heard from you for a while. Can you please re-login to confirm your identity?’. Do tokens have anything to do with this? Yes. You know that the web server stores the token number that T24 sends. These tokens contain a time stamp (time stamp is the time when the token was created + time out specified in the USER record). Assume that the time when the token was created is 10.30AM and the time out specified in the USER profile is five minutes. Then, the time stamp will be 10.35AM (the time stamp is not stored in a 24 hour format but in a native Web Server format). If the user remains inactive past 10.35AM, then, any subsequent request from that user in that session will result in a security violation. At this point, the tokens in F.OS.TOKEN and F.OS.TOKEN.USE will not be deleted. They will be deleted when the user signs on the next time.


16

1.QUESTION : Both sign on and sign off requests does not come in and go back with tokens TRUE FALSE 2. QUESTION : F.OS.TOKEN stores token number that will be used for the complete length of the user’s session TRUE FALSE 3. QUESTION : F.OS.TOKEN.USE contains four types of records TRUE FALSE – only one 4. QUESTION : Token allotted to one user can be used for the requests coming from another user TRUE FALSE – Tokens are user specific


17

In this learning unit/course, you learnt about the Token Processing in T24. You will now be able to: •Describe Tokens in T24 •Explain the need and working of Tokens in T24 •Explain the files F.OS.TOKEN and F.OS.TOKEN.USE


18


20

4. Token Processing.pdf

Recommend Documents