I have recently deployed a Webwork instance locally using the vmware image and following the instructions in the wiki. I subsequently upgraded to version 2.8. If more detailed version or build information would help let me know how I can determine that.
We have ldap authentication set up and it works fine. The issue is, usernames seem to be case sensitive.
When I review /opt/webwork/courses/<course name>/logs/login.log I see the following:
[Fri Feb 21 08:49:34 2014] LOGIN OK user_id=ab1234cd login_type=normal credential_source=params host=x.x.x.x port=61920 UA=Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
[Fri Feb 21 12:24:59 2014] LOGIN FAILED user unknown user_id=ab1234cD login_type=normal credential_source=params host=x.x.x.x port=65255 UA=Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
That is a test with the same account and password, just changing the case of the last character (obviously I obfuscated the username and IP address).
Is this expected or intended? Is there a way we can configure so this doesn't happen?
Thanks for any help you can provide.
Hi Heath,
We have the same issue: Student usernames in Active Directory are not case sensitive, but webwork usernames are. So students will try to login to webwork with all sorts of case and fail.
You can "fix" this by having instructors upload the webwork usernames in all lower case letters. Then put a file named login_info.txt in the templates directory of each course with a message that username must be typed in all lower case letters. This file could be put in the modelcourse as necessary.
Lars.
It shouldn't be too hard to have WeBWorK convert what the student types in the box to lowercase before checking against the WW class list, though I haven't looked at the LDAP code in a long time.
Danny
I think that we fixed this by modifying the Authen.pm file
(full path: /opt/webwork/webwork2/lib/WeBWorK/Authen.pm)
(full path: /opt/webwork/webwork2/lib/WeBWorK/Authen.pm)
Convert Line 406 from
$self->{user_id} = $r->param("user");
to
$self->{user_id} = lc($r->param("user"));
I hope this is helpful. This is called before any actual authentication routines are called.
BTW, I don't know what happens if the database of student ids uses mixed case. Presumably WW uses the student name as the key to lookup the record. Perhaps the database query can be set to be case insensitive?
- Brian
I think the problem with making userID's case insensitive is that WeBWorK uses some URL's that include the userID, and since those map to directory names, and directory names are case sensitive (in most OS), allowing students to use other capitalizations when they log in would cause some URL's to produce 404 errors. At least that is what I remember being the problem.
Thanks everyone for the input. I have used both suggestions, posting a note on the login page as well as using the lc() function in Authen.pm
All of our student accounts are imported from a classlist file generated by a custom report script so I will see if we can rely on those always being lowercase and if not, ask that the script be modified to include a lowercase-type function to keep these consistent.
Does anyone know if Authen.pm could get overwritten with a Webwork update/patch? I assume it could, and in light of that, maybe the lc() isn't the best way to go and informing users to use lowercase is a better approach?
All of our student accounts are imported from a classlist file generated by a custom report script so I will see if we can rely on those always being lowercase and if not, ask that the script be modified to include a lowercase-type function to keep these consistent.
Does anyone know if Authen.pm could get overwritten with a Webwork update/patch? I assume it could, and in light of that, maybe the lc() isn't the best way to go and informing users to use lowercase is a better approach?
Does anyone know if Authen.pm could get overwritten with a Webwork update/patch?
If you are using
If you are using
git to maintain your copy of WeBWorK, then your modifications should be retained when you do an update via git pull. If there is a conflict, you will be warned about that and will need to resolve the conflict by editing the file (it will include both your version and the new version of the conflicting lines, and you get to choose which to keep).