Information
This page captures some possible solutions for the Become User Extension which is a fix for the issues at Become User Problem Space
- Zach Thomas:
Another approach would be to temporarily change the userId to use for
calculating the view of the site. I have some rough code that does
this right now:SakaiSecurity.java has this method: public boolean unlock(String lock, String resource) { return unlock(userDirectoryService().getCurrentUser(), lock, resource); }
Which I have reimplemented like this:
public boolean unlock(String lock, String resource) { return unlock(userDirectoryService().getCurrentUser ().getUserToPoseAsForResource(resource), lock, resource); }
I then added the getUserToPoseAsForResource(String resource) to User,
as well as adding setUserToPoseAsForSite(String userId, String
siteRef) and unsetPosingForSite(String siteRef) to UserEdit.Once you have this set up, you can have your link cause a call to
setUserToPoseAsForSite, passing in the id of some canonical student
user that you have previously defined. When they're ready to go back
to being themselves, they invoke unsetPosingForSite.The problem is that to be effectively real to Sakai (as it works now)
the user must have credentials in the database, unfortunately.
SakaiSecurity calls AuthzGroupService which is implemented as
DbAuthzGroupService, which has various versions of the isAllowed()
method which just query the database.I suppose another way to go about it would be to decorate
DbAuthzGroupService with something that can lookup values in an in-
memory map. The posing-as info does belong in the Session, but it has
to have a per-site scope, since you won't be posing as a student for
all sites in your session.I don't think you'd need a special role, as long as you have
something in the Session that says whether you are in a state that
you can "switch back" from.Looking more closely at the AuthzGroupService interface, it seems to
me that the problem is that the isAllowed methods expect a userId.
From within the method implementation, it then resolves the user to
a role (using the database, naturally):boolean isAllowed(String userId, String function, String azGroupId);
boolean isAllowed(String userId, String function, Collection azGroups);What we really need is for isAllowed to take a role id, and now
instead of calling isAllowed(userId, String function, String
azGroupId) you would first call String getUserRole(String userId,
String azGroupId) and then pass that to isAllowed.Once you can do that, you can have an implementation of getUserRole
that is smart enough to figure out whether to get a temporary value
from session state, or go to the database for the "real" role.Being able to ask the AuthzGroupService about the rights of
particular role eliminates the need to masquerade as some fake user
just to adopt their role. - Jim Eng:
What if you had a pair of roles defined in a site, something like this:
instructor (same as current definition for the instructor role except
with a specific permission that allows the user to switch to
"instructor_as_student" role)
instructor_as_student (same as current definition for the student
role except with a specific permission that allows the user to switch
to "instructor" role)Then you'd need a UI for changing roles within a site and a mechanism
for making the switch temporarily. You'd still have the current
student role, which would be completely independent of the
instructor_as_student role. Unfortunately that means they could be
out of sync, if someone adjusts the permissions of one or the other
role within a site.BTW, in any mechanism for switching roles, the possibility that the
site has groups presents an added complication. - Stephen Marquard:
Your role in the site is not all that's involved. You can have permissions that
inherit from your user type template (!user.template.type).For example we use such a permission in !user.template.staff to allow official
student id photos to be visible to staff users but not students (independently
of their role in the site).Adam Marshall wrote:
> Could all data relating to the fake user be deleted after the switch back to
> the real username?
>
I don't think there would be any realistic way of doing that. For
example, what if the preview user edited a wiki page, and someone else
edited it after that? You couldn't roll it back and you'd have a "ghost
edit" in the middle. OTOH if these users can't make any changes, then
the goal of "viewing the site as a student" is not met.I think one would need to create a persistent preview user keyed to the
original user, site and preview role, i.e.preview_userid = preview_uid_siteid_role
These would last until the site was deleted. A couple of tools would
need to handle them in special ways, e.g. Site Info, Roster,
Assignments, Gradebook, to basically not display them or include them in
exports.A whole bunch of tools would have kept the userid in tool storage for
any artefacts or changes that the previewuser made (e.g. posted forum
message, edited wiki page, uploaded file). Perhaps you could get the
userdirectoryservice to return a default "Preview User" username and eid
for getUser() calls for these ephemeral users.That would solve the case of the user not showing up and also wouldn't
lead to unexpected results elsewhere. - Clay Fenlason:
disabling events for a fake user would not meet a set of our
requirements. Our instructors don't just want to see a screen as
though they were the student, they want to carry out mock actions as
well (e.g. submit an assignment, take a quiz). They are not testing
only static screens; they are checking behavior.At the same time, admin support needs to know who is carrying out
these actions. It would be ideal, in concept, if they simply adopted
a new role+type mantle for authorization without shifting their unique
identity.It is more important for us to not lose the information of who did
what than to have "purer" event statistics. - Aaron Zeckoski:
The concept we have toyed with a little bit while at the Fluid summit
was to generate a fake user on the fly which has an id which is the
original user eid (or id) plus a prefix or suffix (or both). The idea
is that it would be fairly easy to identify the fake user activity and
also to figure out who the real user was.This is very preliminary but I think the concept is relatively doable.
Still needs a proof of concept though.The preliminary idea we had was to remove the user after the
previewing session (though an alternative would be to simply disable
them). Either of these would achieve the effect of allowing the user
to behave like a real one and not appear in the various tools since
they would be removed shortly after the previewing.There may very well be long and complicated ways of doing this but
this is meant to be something that can be accomplished fairly quickly
and without modifications of tools and services (maybe really minimal
modifications of a service or 2).Just ideas right now but I think the simple approach is the right one for now.
- Casey Dunn:
How about this -
the fake student user is your std student sakai type (as if) with a
canned my workspace. this my workspace as a jump-back tool.hold on to that thought.
oh yeah, and there is an official fake student boiled into the provider
or as a local user (admin, postmaster, synchrobot)the switch-to-student tool scrapes out the current users session but retains
the switchers session id and a new binding for original Id. this allows
sakai-events
to be posted in such a way that they leave an audit trail back, as the
switch-to-student tool leaves an event breadcrumb.when the switcher wants to switch back they use the jump back tool. another
sakai-event breadcrumb is left. the original EID/ID can be stored in the hijacked session.