IMO It would be worth while refactoring the security into a single encapsulated "thing" which is available at a global level.  A single encapsulation.

Status: "Locked/Unlocked/login_attempt(detect when user is submitting form)

User: "username" (used by dojoConfig);

ECLWatchUser: "true" (user entered through ECLWatch);

1. ESPSessionState: true/false validates whether or not there is an active session, used in stub.htm

I'll let Miguel comment on the other eclwatch cookies he uses, Kevin mentioned the other cookies above.

@Gordon Smith so far, 7 cookies are created by ESP:

1. ESPSessionID: identifier for a valid ESP session

2. ESPAuthURL: the URL where ESP will redirect to after user's password is found to be valid and new session is created. For example, to access an ECLWatch page before logged in, a user may type in http://ip:port/#/stub/Main-DL/Event-DL/EventScheduledWorkunits. ESP stores this URL into the ESPAuthURL cookie and redirects the user to the login html.

3. ESPAuthenticationMSG: the error message when a user is failed in authenticated.

4. ESPAuthenticated: indicates that a user has been authenticated or, in ESP UserNameOnly mode, the user name is received.

5. ESPSessionTimeoutSeconds: the session timeout seconds

6. ESPAuthIDTemp: store the userid when a password is expired and a user is redirected to the update password input form. The userid is needed for updating password. 

7. ESPUserName: this cookie is only used in ESP UserNameOnly mode to store the user name.

ECLWatch UI code also creates some cookies. @Miguel Vazquez @Kunal Aswani may list them here.