Session Object
Description
The Session object is used to work with the server session. The Session and Context.Session object are the same and can be used interchangeably in Xbasic scripts running on both the Classic Application Server and Application Server for IIS. See Context.Session for a list of properties and methods for the Session object.
Sessions
Web requests are stateless, that is each request from a client (web browser) to a server is separate from any previous requests and no information about previous requests is available to the current request. You should think of each page as a separate Xbasic script - once one is finished, the next knows nothing about the previous. This can make the building of web applications quite difficult as the developer needs to track this state information within each web page returned by the server.
The Classic Application Server and Application Server for IIS use sessions and Session Variables (as explained below) to overcome this limitation of web servers. As long as the Application Server is licensed to handle the number of active requested sessions, a request from a new client will cause a new session to be created. The server will then associate future requests from that client with the same session until the session expires or is explicitly abandoned. A session expires when a request has not been received from the associated client within the time period set by the Session Lifetime.
Sessions are tracked with cookies. If cookies are not enabled on a specific client computer, the server cannot track the session.
Support for cookieless session tracking was removed from the Classic Application Server and is no longer supported in Alpha Anywhere build 4811 or newer. This eliminated the small possibility that previously existed of "session hijacking". Your application users must support cookies in order to use sessions with the Classic Application Server.
When a session is created by the server, some information is automatically stored in it - the session ID and a timestamp. As an application developer, you can also store other information in the session in order to make it available to subsequent requests without explicitly passing it to that request.
To create a "session" level variable, simply name it session.varname. It will then be persistent across all page views and can be later referenced as session.varname in subsequent pages.
To illustrate this limitation of web programming and the session solution, look at the following example.
<%a5 greeting = "Hello World" %> <HTML> <HEAD><TITLE>Session Variables</TITLE></HEAD> <BODY> <%a5 ? greeting %> </BODY> </HTML>
<HTML> <HEAD><TITLE>Session Variables</TITLE></HEAD> <BODY> <%a5 ? greeting %> </BODY> </HTML>
In the example above, the second page has no access to the variables created in the first, so an error is generated when the second page tries to use the undefined variable greeting. But if the variable is instead created as Session.greeting it will be available to all pages using the same session as can be seen below.
<%a5 Session.greeting = "Hello World" %> <HTML> <HEAD><TITLE>Session Variables</TITLE></HEAD> <BODY> <%a5 ? Session.greeting %> </BODY> </HTML>
<HTML> <HEAD><TITLE>Session Variables</TITLE></HEAD> <BODY> <%a5 ? Session.greeting %> </BODY> </HTML>
Session Variables
The values automatically stored in each session by the server are documented in Context.Session. Context.session and session are the same object and can be used interchangeably. Variables added to the session object using either Context.Session or session can be accessed by either.
Session variables have global scope and are visible to any functions you may call from you A5W page.
Session ID
A Session ID is a unique ID that the Application Server assigns to each client. It uses the session ID to keep session information associated with the appropriate client. When the client sends a request to the Application Server, it needs to include this session ID so that the server knows which client is making the request.
The Application Server will use a cookie to track the user's session ID.
When the session times out, the Application Server will issue a new session ID when the user reconnects. Any session variables that were associated with the user's previous session will no longer be available and must be recreated.
Additional Topics
- Name
- Description
- Understanding and Using Session Variables
When you create an Xbasic variable inside an A5W page, the variable is not available to other pages. If you want to reference a variable on multiple A5W pages, you must use a session variable to store the value. Session variables are available for the duration of a session to all A5W pages in an application.
- Storing Files in Sessions
Session storage is able to deliver robust and scalable server solutions. In order to enable this feature, data intended to be stored on disk at the session level should use context.session.SaveDataAsFile(). This stored file can then be linked to using context.session.FormatFileDataURL().
- Referencing Session Variables on the Client
Session variables are only available on the server unless they are explicitly published to the client. Published session variable are read-only and cannot be modified by the client.
- onSessionCreated Session Event
The onSessionCreated system event, which fires when a new session is created in IIS and Alpha Cloud, can be used to add Xbasic for setting up session variables.
See Also