01:58:32 AM
3EG048IP0
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
