Hi Scott,
according to my experience about session management, client and servers
should operate as in the following:
- Normally, a session/login followed by another session/login should
result in opening a new session on the server with a new session cookie.
- The server sets the session cookie once the session/login is received,
the client includes the session cookie received from the server in any
RDAP request within the scope of that session including session/refresh,
session/status and finally session/logout.
- If the client sends any request other than session/login including an
unknown cookie, the server must return an error.
- If the client sends a session/login request including a cookie, the
server could return an error or ignore the cookie received by the client
and hence provide the client with a new session cookie. To be decided
what should be the server's behaviour in that case.
- A server can refuse to open a new session after a session/login if a
maximum number of concurrent sessions per user exists and the client
exceeded that limit. This is to prevent servers from resource starvation.
- A session can be removed by the server due to timeout expiration or
because a maximum session lifetime exists, regardless the fact that the
session ia active, and the session has exceeded that limit. This is to
prevent server from handling inactive sessions and indefinitely opened
sessions.
Best,
Mario
Il 07/07/2022 17:01, Hollenbeck, Scott ha scritto:
Thanks, Rick. Trimming things up a bit and changing the subject
appropriately...
In the last sentence: Is the client required to wait until the access
token has
expired before submitting the new login request? Or can it send logout
and
login back-to-back? (Or even just a login command while currently logged
in?)
[SAH] Let's talk about this. What's appropriate behavior? IF the server
gets a
"login" during an active session, it can either ignore the second "login",
or it
can return an error. Similarly, it the server gets a "logout" when there's
no
active session, it can either ignore the "logout" or return an error. I'm
inclined to return an error to explicitly note that the submitted
query/command
wasn't processed as requested.
[RW] First off, I will certainly defer to those with more implementation in
this
realm. However, based on my experience as a user, I would expect a login
that
happens during an active session to "just work" and override the previous
active
session. This could happen when I have an active session at the server but
the
client browser (with the session) crashes or is otherwise inaccessible.
This
seems better than the alternative: If the new login request is refused,
then
the user is (essentially) locked out until the session timeout value
expires.
Related, if the server gets a "logout" when there is no active session, I
think
that it should ignore the "logout" (rather than returning an error). The
thinking being that returning an error is at best useless and at worst could
be
an information leak (aka security risk).
The document currently describes a session/refresh path segment to perform the
kind of "override" behavior described above. Having a "login followed by a
login" do the same thing seems counter-intuitive. My own experience with
server-side session management is that there is no lockout. If the client
sends the right HTTP cookie, and the session is still active, there won't be a
problem. Another login should be possible if the "old" session gets corrupted.
Let's look at the server-side options again for situations in which the server
receives a login followed by a login, or a logout where there's been no login,
or a refresh without an active session, or a session status without an active
session:
1. Return an error. HTTP includes a 409 (Conflict) response that can be
returned if a received request conflicts with the current state of the server.
2. Accept the request and ignore it. I'm not sure what an appropriate HTTP
response code would be for this situation.
3. Accept the request and do "something".
Option 1 can be done consistently for all the above request sequences. Option
2 seems like it could mislead the client into thinking that something has
happened unless there is, in fact, an appropriate HTTP response code available
to describe a no-op (I couldn't find one). Option 3 might be doable if we can
figure out what the "somethings" are, like processing a second login received
while a session is active, but the other command sequences present problems.
As you described above, a logout received without an active session is
processed differently than the "login followed by a login" situation. Is that
really the best course of action? I think consistent behavior would be
preferred.
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
