John,
OK, I see where I was getting mixed up. The session timeout can be a
different length than the process timeout. But in practice the session
ceases to persist on 4D unless it's active in a process. So when the
process providing the context for the session expires that 'session id'
goes too.
No direct experience on that, but here are some debugging ideas:
- Do you have all the parameters declared in On Web Connection and on Web
Authentication?
- Put a trace in On Web Session Suspend to see if the session is getting
suspended. Might be a bad timeout setting?
- Are you changing any
John,
Well that's good news - and I must be inadvertently doing something to
subvert it. Have you stumbled onto things that do would cause 4D to ignore
it?
On Fri, Apr 14, 2017 at 5:51 PM, John DeSoi via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> Hi Kirk,
>
> > On Apr 14, 2017, at 11:33 AM,
Hi Kirk,
> On Apr 14, 2017, at 11:33 AM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> But that's not the way I see it actually work. A new process spins up each
> time new request comes in and gets assigned a new web session id which
> replaces whatever the 4DSID cookie is.
Since I'm focused on the webserver today, I'm coming back to not being
clear on the distinction 4D makes between a 'web session' and the 'web
process' when using automatic session management.
A web session, as I understand it, is an authorized connection between a
browser and the server and
5 matches
Mail list logo
