Deal with session handling. #1505
Conversation
|
For learning purposes: Could you explain why a sessionUuid is needed in addition to sessionId? Where does it function, and what is its relationship with sessionId? |
| */ | ||
| function saveSessionMap(window, map) { | ||
| const mapArray = Array.from(map) | ||
| const json = JSON.stringify(mapArray) |
There was a problem hiding this comment.
Why convert this to json?
There was a problem hiding this comment.
Because the "sessionStorage" only knows how to save "string => string" object types.
It is not designed to save javascript "Map". So you have to serialize/deserialize it.
There was a problem hiding this comment.
I stared at it for a while in confusion, until I realized this to make it work......
|
|
||
| // Session handling constants | ||
| const SESSION_KEY = 'session_uuid' | ||
| const APP_ID_KEY = 'stsApplicationId' |
There was a problem hiding this comment.
What exactly is an appId?
If a user opens 2 Z3Light applications then do we have 2 appIds for it or the same app Id?
Similarly what exactly is an Iframe in terms of a sample application?
There was a problem hiding this comment.
"appId" is really a unique identifier for each "iframe". When an IDE opens multiple copies of ZAP in multiple iframes, each one gets one of those "appId" unique keys.
"iframe" in that context, is basically a separate ".zap" file. If you open 3 .zap files, you will have 3 iframes.
@ethanzhouyc : after this change the "sessionUuid" and the "sessionId" are one and the same thing. Before the change, the session ID was the uuid + appId, but now we're no longer propagating the appId into the back-end, we're merely using it as a key to the map between appId and uuid, and only the uuid travels to the back-end as a "sessionId". |
This should resolve issues related to session handling.
There are two modes of operation:
1.) WITHOUT a passed appId, in which case we simply use a default value, and map the uuid to that key.
2.) WITH a passed appId (which is called "stsApplicationId" on the query string). In this case, this appId is being used to key the uuid inside the session map.
The second case is used when zap is rendered inside a system with multiple iframes, which share the same "sessionStorage", so you have to kepe session separate. That's why you can't simly use session storage directly.
The map ensures two things:
1.) When an iframe refreshes, with the same appId, it will reattach to the same sessionId.
2.) When a whole new iframe is created, and a new appId is passed, the whole new uuid will get created.