Use of cookies and browser memory
map.apps uses cookies and browser memory (Local Storage and Session Storage) to store data across browser sessions. This page provides information about what data is stored.
Browser memory (Local Storage / Session Storage)
The following section describes which bundles store data in the browser memory. Only those bundles are taken into account that are included in a delivery by default.
Bundle | Description | Trigger |
---|---|---|
|
Stores the state of the Saving this data is not active by default.
It only becomes active when the property |
Access to protected resources of ArcGIS Online/ArcGIS Enterprise portal or ArcGIS Server. |
|
Users have the option to suspend checking for available bundle updates for a selected period of time. The time span is stored in the Local Storage. |
Open map.apps and suspend checking for bundle updates for a selected period of time. |
|
The ArcGIS Maps SDK for JavaScript uses the browser’s Session Storage to store secret values, which must be randomly generated and stored when authenticating via the OAuth protocol. |
Authentication of the user is done via OAuth protocol to ArcGIS Online/ArcGIS Enterprise portal. |
|
Stores the time of the last usage of the application in the local storage to be able to log out users automatically after a certain period of time. |
Using map.apps. |
Cookies
Please note the following about the descriptions below:
|
Cookies are used in map.apps to assign users to a session after they have successfully logged in. It depends on the authentication mode which cookies are used:
-
In the integrated authentication mode sessions are managed by Tomcat. When a new session is created, a cookie with the name
JSESSIONID
(name may differ, see above) is sent to the browser. -
If the authentication is done via con terra Technologies Identity Service at an external identity provider, an
ctIDENTITY
cookie (name possibly different see above) is written. -
If security.manager - Enterprise Edition is used for authentication, an
ct_SSO
cookie (name may differ, see above) is written to implement domain-wide single sign-on.