** Using WeBWorK **

At Ohio State students and faculty are assigned usernames of the form
lastName.####
where #### is an integer used to make the username unique. In 
WeBWorK 2, the lib/WeBWorK/DB.pm function checkKeyfields disallows 
the  character '.' in usernames. I modified this and submitted a 
bug/feature request and got the following response from Sam:

>adding dot as a valid key field character is not an option at the
>moment, because dot is used in the names of form fields (i.e.
>$userID.$fieldName). This restriction will be lifted in the future,
>it's just a question of auditing the code to make sure nothing
>will go awry.

So precisely what problems will my modification cause in WeBWorK 2?
And what workarounds would you suggest?

<| Post or View Comments |>

A workaround would be to modify the classlist importing code (in WeBWorK::Utils::Classlist) to replace "." with some other character. I advise against blindly removing character set restrictions.

There have been significant changes to WeBWorK since I first looked into this problem. It may not even be an issue anymore. I am checking into it. Please be patient or take a look at it yourself.

Thanks.
-sam

<| Post or View Comments |>

http://bugs.webwork.rochester.edu/show_bug.cgi?id=354

<| Post or View Comments |>

I looked at this a little for allowing periods in set names. Things looked pretty good, but I hadn't done enough checks to be completely confident.

For what it is worth, I did grep through the sources for split commands. I found places which split on commas, colons, etc. but not on periods. I realize that isn't conclusive since it may be used without an explicit split command, but it is a good sign.

I may run with periods in set names for a while as one sort of test, while looking through all the content generator modules for places it might come up. Zig may want to do the same with user names.

John

<| Post or View Comments |>

John - Thanks for taking a look.

I have been looking as well. So far, all the places I've found so far that use dots to join user IDs and other values are harmless, because of how the composite values are used.

• In UserList, values are retrieved the same way they are constructed, by concatenation. So this is not a problem.
• In PGProblemEditor, ProblemSets, and ProblemSet, temporary files are named "$fileName.$userID.tmp", but they are retrieved by construction, which is OK. (By the way, that use of the user ID has to go for unrelated reasons.)
• In Hardcopy, saved hardcopy files are named "$courseName.$fileNameUser.$fileNameSet.$ext". This is not a problem, since the name is never read and parsed.

This is probably not complete, but it's all the places I could think of where dots might be used along with user IDs. But it's a good sign that all of these have turned out to be innocuous. Rob and Mike might have more to say on the matter.

<| Post or View Comments |>