Using JSDOs to create mobile and web clients : Managing JSDO login sessions
  

Managing JSDO login sessions

The first task in accessing a Data Object resource with a JSDO is to create a JSDO login session for the web application that provides the Data Object Service and resource you need. You can create a JSDO login session by calling the login( ) method on an instance of one of the following OpenEdge JavaScript classes:
*progress.data.JSDOSession class — (Recommended) Supports asynchronous access only to a web server using jQuery Promises that are returned by JSDOSession methods (such as login( )) for registering callbacks to handle the results. Each instance of this class enforces access to a single web application that supports Data Object Services using the application's configured web server authentication model, as specified by options passed to the class constructor. This means that once created, a single JSDOSession instance can be used to access only the web application for which it is created. Progress recommends that you use this class because it enforces the most typical web authentication pattern for a client app that accesses a web application. For client web apps, this includes the option to maintain an existing JSDO login session when the user initiates a page refresh on the browser page that is running the app (available in Progress Data Objects Version 4.3 or later).
*progress.data.Session class — Supports either synchronous or asynchronous access to a web server, with Session methods either returning synchronous results (the default), often including a method value, or optionally returning asynchronous results using callbacks that you subscribe as event handlers prior to calling the method. Each instance of this class can be used to access any web application that supports Data Object Services, and can be re-used to access any other such web application, using that application's configured authentication model, which you specify as part of calling the instance's login( ) method. This means that once created, a single Session instance can be used to access a different web application once any current web application has been logged out using the logout( ) method. Progress deprecates this class in favor of progress.data.JSDOSession, though you do need to use a Session instance if your client environment does not support jQuery Promises (or the exact equivalent). Note: A client environment based on Kendo UI supports jQuery Promises.
Using an instance of either class, the login( ) method takes any required user credentials as input and once authenticated on the specified web application, establishes a JSDO login session for it.
The successful result of calling login( ) is typically user authorization to access the resources of Data Object Services hosted by the web application. Once user authorization is obtained, you then call the addCatalog( ) method on the session instance to load one or more Data Service Catalogs for the Data Object Service or Services you want to access. You can then create a JSDO for a Data Object resource defined in any of the loaded Catalogs.
However, before invoking this login sequence, you need to gather some information, depending on the session class instance, to determine how best to configure and code it. You also might want to manage client app execution based on whether the login session and its connected Data Object Services are online and available over the network (session online status). You can do this for a JSDO login session with the help of a particular set of session events, methods, and properties.
The following sections describe how to prepare for and manage these tasks:
* Requirements for creating a JSDO login session
* Using default web pages to support client app login
* Handling changes in session online status
* Using protected web resources