Maintaining Session
maintain-session-context.png

Servers

REST API

  • This is the main server of concern because it is the only one whose session we care about. The other servers are interesting either because:
    • They source the application from a different domain from the REST server.
    • They serve other requests to the application other than REST (auth and SSE) and may carry info that we bring to a session.

Dev Server

Serves up the application as a browser client and offers a different host of origin. (ionic serve in our case).

  • Provides a different domain from the REST server.
  • This presents CORS issues.
  • The source domain of JSESSIONID cookies is not the same as the host of origin.

Auth0

  • The third-party authentication service resides at a different domain.
  • There is also a different domain for the callback.

Not clear how this interaction may or may not be a factor.

Server-Sent Events (SSE)

  • These are subscribed to by one of the clients to establish a "push" service from the server to the client.
  • Instead of a session, an outing ID is used to identify the channels of interest.
  • State information that is pushed is not sensitive EXCEPT for the GPS information broadcast by the Guide.

Clients

Postman

  • Hitting the REST API is the primary use of Postman.
  • Authorization header is the primary identifier of a registered app.
  • Session information is carried in a JSESSIONID cookie specific to the domain which will match the domain of the REST API.
  • Expectation is that sessions are preserved between calls — once a JSESSIONID is obtained, the same session should be provided to each call into the REST API. I don't think this is happening right now.

Browser

  • This is the main development environment.
  • The environment is limited by its ability to emulate native functionality; for example, it doesn't permit the establishment of authentication tokens using the 3rd-party authentication service (shown as a dashed line in the diagram). A workaround is to use a configurable test token. Camera and GPS are two other examples of limited functionality.
  • Another constraint is the CORS issue that comes into play as the application's JavaScript is loaded from the domain where ionic serve resides and the REST calls are a different domain. It is possible to proxy the app so a single domain is used.
  • CORS configuration is another method of avoiding the cross-domain constraints by explicitly permitting these calls.
  • Since the browser picks up — or is expected to pickup — the JSESSIONID cookie from the REST API server, it is also expected to present the cookie with requests. It doesn't appear this is happening right now.

Native

  • This is the main production environment, a native application running on a mobile device.
  • Note that features of the browser are still available alongside the native capabilities such as Camera and GPS.

BDD / Headless Chrome

  • This is similar to the Dev environment — Browser restrictions are mimicked by the headless Chrome browser.
  • The significant addition is a separate client which drives the headless chrome browser; it's an additional layer.

References

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License