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

Using protected web resources

It is possible to configure a client app so that, prior to logging in, it opens a protected web resource. A protected web resource is typically a web page provided by a web application that is protected according to either the HTTP Basic or HTTP Form-based authentication model. If the client app attempts to open a protected web page prior to obtaining and authenticating the user's credentials with a call to the login( ) method on a newly instantiated JSDOSession or Session object, either the browser running a web app, or the mobile device container running a hybrid app, automatically prompts the user for login credentials and sends them directly to the web application for authentication.
Note: For typical web applications configured to use HTTP Form-based authentication, when a client app tries to access a protected web resource without prior authorization, the web application sends a web page containing a login form to the web client for the user to enter login credentials for authentication. However, the JSDO handles HTTP Form-based authentication differently, and never uses the web page that is sent to a client app. Instead, the JSDO relies on the client app to provide the login form, exactly the same as for HTTP Basic authentication.
If authentication for access to this protected web resource succeeds, the web application then returns the protected web resource to the browser or device container for display to the user. At this point, the client app must also call the login( ) method to initiate a login session in the web application in order to access any of its Data Object Services. However, in this case, because user authentication has already occurred, there is no need to pass user credentials, and if any are passed, the login( ) method ignores them. In fact, the client app does not even know the username provided by the user who authenticated against the protected web page prior to this call to the login( ) method.
In general, because of differences between typical app and JSDO support for HTTP Form-based authentication, with its separation between user authentication and the need to call the login( ) method to start a JSDO login session, configuring a client app to access a protected web page prior to invoking the login( ) method is not a typical client app configuration when using a JSDO. Instead, Progress recommends that a client app only access unprotected web and Data Object resources until the app explicitly prompts for user credentials using an unprotected login page that the client app provides, then calls the login( ) method to both authenticate the user and start the required JSDO login session for the web application.
That being said, Progress also recommends, and helps to ensure, that the login( ) method itself accesses a protected web resource as a login target when starting the JSDO login session. In general, you need to be sure that security is configured to complete authentication and load the Data Service Catalog before a client app requests resources in the Catalog. Although it is possible to configure web application security so that Data Object resources in the Data Service Catalog are the only resources that require web server authentication as part of the call to the addCatalog( ) method, doing so can cause problems when a client app that otherwise authenticates successfully tries to access the Data Object Services that the web application provides.
In other words, in certain situations where a Data Object resource is the first web application resource to require authentication, a client app can be prevented from accessing the resource even after an authenticated JSDO login session starts successfully. Therefore, Progress provides defaults so the login( ) method always accesses a protected non-UI web resource before the client app attempts to access a protected Data Object resource defined in the Data Service Catalog. Once the user is authenticated against this protected web resource, the web server can then reliably provide access to similarly protected resources of the web application—including Data Object resources—according to the user's authorization settings (roles). For more information on the default protected web resource for the login( ) method, see Using default web pages to support client app login.