You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should explicitly make room for events where the actor of a Session Event is manipulating a Session who's user is some other user (that is the Event's actor is User A, but Session.user is User B). This would allow us to talk about these use cases:
users being logged out by daemons or administrators, and distinguishing those cases from a user logging themselves out
users being "impersonated", or proxied, by another user (this is a common LMS use-case: "instructor impersonates student in order to submit quizzes left unsubmitted on student's behalf" and similar things).
In order to support these cases, I propose we do two things:
explicitly describe as possible SessionEvent.actor being different to the event's contained Session.user; as far as I can see, this might be allowed right now because I'm not sure we forbid it; but we don't say anything about it.
put a new property on Session called actualUser: the Session.user field identifies the "logged in user" that "owns" the session (i.e when the system is checking ownership of objects, or permissions, etc, then it treats the session as "being" Session.user); if there is another user behind the session who's proxying "as User B", then the Session.actualUser field captures that -- note this aligns in general with the limited support that LTI has for this concept.
The text was updated successfully, but these errors were encountered:
ViktorHaag
changed the title
Caliper session profile, and Sessions, should support proxied sessions
Caliper session profile, and Sessions, should support proxied sessions, "actual user"
Mar 19, 2020
We should explicitly make room for events where the actor of a Session Event is manipulating a Session who's user is some other user (that is the Event's actor is User A, but Session.user is User B). This would allow us to talk about these use cases:
In order to support these cases, I propose we do two things:
actualUser
: theSession.user
field identifies the "logged in user" that "owns" the session (i.e when the system is checking ownership of objects, or permissions, etc, then it treats the session as "being" Session.user); if there is another user behind the session who's proxying "as User B", then the Session.actualUser field captures that -- note this aligns in general with the limited support that LTI has for this concept.The text was updated successfully, but these errors were encountered: