01:05:56 PM
3EG0S2QHS
Thanks for taking the time to explain it, especially since for you, living so close to this, it is probably obvious.
It also seems some of this architecture is based on wconnect. Having used numerous web connection products, I do not see why their would be a separate user id from the session id. Typically once a user is established, say user XYZ, we would start a session. When the app logs that XYZ user off, either directly or thru a timeout or window closing, the session is closed.
We have at least 2 reasons for identifying a device-browser couple by the default wwSession.NewSession() and wwResponse.addCookie() naming scheme based on sys(2015) rather than by using Transform(<application user ID>):
- a security reason: exposing application user PK over the wire could be a severe security breach;
- a practical reason: application user PK may be of various types (mainly C or I) and length (GUID is 38, str(int()) is 10, natural PK is variable, etc.); using this data as session identifier would be quite unpredictable.
User session is established at the very first request, when user gets into the site;
Storing application's user ID into user session happens as soon as wUserGet() returns a NOT .NULL. value.
It sounds like wconnect is running one session with multiple user ID's, more 1-n, than n-n. I wonder why they do it this way, maybe I will ask them. Meantime I reply more specificaly about this issue and FiC separately.
As you know, wConnect supports up to 32 COM instances of the same wConnect/FIC server on a given OS.
All these instances share a common wwSession table to manage sessions.
Sorry for all the questions. Every day I find new features and abilities in FiC I never knew were there, and I always like to try everything!
You're welcome!
Walking forward implies putting one foot ahead of another.
thn
