Hi,
The only valid characters in the user_id seems to be [-a-zA-Z0-9_.,] (or at least, it is only possible to assign users with id in [-a-zA-Z0-9_.,] according to DB.pm) . When importing the user_id from an external database, this is problematic. In our situation, we use WWassignement and thus, users are logged in to Webwork via Moodle. Since our Moodle users authenticate by Shibboleth, we have no way to control the user names.
At the moment we only use an identity provider for which we know the following format of the user names: abcdABCD@host.suffix (a,b,c,d are letters and A,B,C,D are integers in [0,9]). Thus, a possible hack would be to let the valid characters in an user's id be [-a-zA-Z0-9_.,@]. This seems to work, but we are going in production in about one week and I really would like to know if this hack causes any unexpected troubles!
Thanks,
Samuel
The hack caused the following serious problem: Problems in a problem set does not show up when logged in as a user with a "@" in the user_id. Instead, the text "This homework set contains no problems" is displayed.
For normal users, everything works fine.
I tried to track the problem. I ended up in a function called get_field_where in /opt/webwork/webwork2/lib/WeBWorK/DB/Schema/NewSQL/Std.pm.
It is called from
listUserProblems in
/opt/webwork/webwork2/lib/WeBWorK/DB.pm, which is called from
body in
/opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/ProblemSet.pm.
Something strange is happening in the get_field_where. I do not have enough knowledge of perl to understand what. (But I know that the user_id is passed ok from ProblemSet.pm to DB.pm.)
I really would appreciate some help on this. It would also be of good for the community since allowing "@" in usernames is the first step towards Shibboleth authorization.
Samuel
For normal users, everything works fine.
I tried to track the problem. I ended up in a function called get_field_where in /opt/webwork/webwork2/lib/WeBWorK/DB/Schema/NewSQL/Std.pm.
It is called from
listUserProblems in
/opt/webwork/webwork2/lib/WeBWorK/DB.pm, which is called from
body in
/opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/ProblemSet.pm.
Something strange is happening in the get_field_where. I do not have enough knowledge of perl to understand what. (But I know that the user_id is passed ok from ProblemSet.pm to DB.pm.)
I really would appreciate some help on this. It would also be of good for the community since allowing "@" in usernames is the first step towards Shibboleth authorization.
Samuel
Hi Samuel,
Did you get any warning messages at the bottom of the page in this case?
My guess is that the problem is that the '@' symbol isn't getting escaped properly, and is therefore being expanded as an empty array in the Perl code that's trying to get the data. I'm interested that it doesn't appear to cause the same problem when the user logs in (at which point the system has to look up the user by user_id), however.
I tracked the listUserProblems call down to the base sql call in SQL::Abstract, and on this pass, at least, didn't see any problem with the '@' in the user_id down to the SQL handle preparation.
Gavin
Did you get any warning messages at the bottom of the page in this case?
My guess is that the problem is that the '@' symbol isn't getting escaped properly, and is therefore being expanded as an empty array in the Perl code that's trying to get the data. I'm interested that it doesn't appear to cause the same problem when the user logs in (at which point the system has to look up the user by user_id), however.
I tracked the listUserProblems call down to the base sql call in SQL::Abstract, and on this pass, at least, didn't see any problem with the '@' in the user_id down to the SQL handle preparation.
Gavin
Hi Gavin!
No, I did not get any warning messages. And I agree that it seems odd that I am able to log in and access the problem set (but with the hack allowing "@").
By the way, it is easy to simulate the problems I get. Just allow "@" and add a student with a user id containing "@". Assign the student to a problem set and then log in as the student.
I printed the user_id on the screen from listUserProblems and it displayed properly. I really wonder where the problem is!
Samuel
No, I did not get any warning messages. And I agree that it seems odd that I am able to log in and access the problem set (but with the hack allowing "@").
By the way, it is easy to simulate the problems I get. Just allow "@" and add a student with a user id containing "@". Assign the student to a problem set and then log in as the student.
I printed the user_id on the screen from listUserProblems and it displayed properly. I really wonder where the problem is!
Samuel
Maybe I didn't make myself clear in the last post.
The problem is that listUserProblems returns an empty list when the user_id contains "@". The print statement displays the user name correct, so it does not seem to escape improperly.
sub listUserProblems {
my ($self, $userID, $setID) = shift->checkArgs(\@_, qw/user_id set_id/);
print CGI::p("userID: ($userID)");
my $where = [user_id_eq_set_id_eq => $userID,$setID];
if (wantarray) {
return map { @$_ } $self->{problem_user}->get_fields_where(["problem_id"], $where);
} else {
return $self->{problem_user}->count_where($where);
}
}
What about workarounds? If it is an escape problem, I guess it would be possible to use something like quotemeta on the user_id when it is first defined. It would also be possible to simply remove the "@" from the user_id. Is verify_normal_user in Authen.pm the correct place to do that?
The problem is that listUserProblems returns an empty list when the user_id contains "@". The print statement displays the user name correct, so it does not seem to escape improperly.
sub listUserProblems {
my ($self, $userID, $setID) = shift->checkArgs(\@_, qw/user_id set_id/);
print CGI::p("userID: ($userID)");
my $where = [user_id_eq_set_id_eq => $userID,$setID];
if (wantarray) {
return map { @$_ } $self->{problem_user}->get_fields_where(["problem_id"], $where);
} else {
return $self->{problem_user}->count_where($where);
}
}
What about workarounds? If it is an escape problem, I guess it would be possible to use something like quotemeta on the user_id when it is first defined. It would also be possible to simply remove the "@" from the user_id. Is verify_normal_user in Authen.pm the correct place to do that?