Use protected web resources
- Last Updated: May 30, 2019
- 3 minute read
- OpenEdge
- Version 13.0
- Documentation
You can configure a client app so that it opens a protected web resource prior
to logging in. 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
instantiating a session using getSession( ), 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.
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 call getSession to initiate a session in
the web application 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 getSession( ) 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
getSession( ) 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 getSession( ) method to start a JSDO login session,
configuring a client app to access a protected web page prior to invoking the
getSession( ) 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 getSession(
) 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
getSession( ) 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. Progress provides defaults so the getSession( ) 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 getSession( ) method, see Use default web pages to support client app login.