Re: ActiveX controls

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.

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 replie more spcificaly about this issue and FiC separately.

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!

Hi Tuvia,
Please find my answers below
HTH,
ThN

I'm sorry, I am still not getting it. Bear with me if you would.
I'll try my best to be more clear ...

I think what you are calling the application ID is what I call a session ID. The ID identifies the unique combination of
application and user that allows the emulation of a state, since http is normally stateless.

What I call "application user ID" is indeed ... user ID for application
In most cases, it is a USER table PK: a surrogate PK such as an integer or a GUID, or a natural PK such as an email address, or whatever PK scheme your application relies on.

- What is the connection between the session ID and the message? -
FAS handles a session ID in the wConnect way, with a simple Sys(2015).
This session ID is the value of a cookie related to the application, FoxInCloud.js adds it as a request parameter (in both URL QueryString and Post data) to each outgoing AJAX request, FAS supplies it back into XML response.
FAS gets this "session ID" with wwRequest.QueryString()/Form() and retrieves user's session from session table using wwSession standard mechanism.
FAS stores "application User ID" into this session record using wwSession.SetSessionParameter() so that it can retrieve and feed it into wUserSet() before executing any request.

- Why is userset/get identified as optional if it is really not? -
wUserSet/Get are optional for public Web applications, without the need for user authentication;
implementing them is mandatory for any application with a user security feature.

- Is it sufficient to make one empty call to userset in the xxxenv.prg?
As any Web application instance can serve any user (n-n relationship), FAS calls:
- before each request wUserSet() to let application know which user (in the application sense) is currently requesting,
- after each request wUserGet() to store application user ID into web user's session record.
FiC developer should implement wUserSet/Get either in the application process object (xxxProcess AS awProcess AS wwProcess), or in some subclass of aw.vcx!awFrm

- Please outline what is happening here.
From the information you supplied, I suspect wUserSet/Get should be revised or implemented

- Why did it only start with 1.06?
Please review FoxInCloud version history supplied with each new version FoxInCloud Application Server release.
You'll see that nothing changed in V 1.06 regarding user identification, and/or wUserSet/Get()

---