Dear Colleagues,
On our system, instructors cannot edit course.conf, but they can edit files in the templates subdirectory. The files in both directories have the same permission level, so I wonder why this is the case...
Is this how it is supposed to be? If so, what is the reason the instructor can't edit course.conf
Sincerely,
Lars.
Hi Lars,
You have to have "admin" privilege to edit course.conf. "professor" privilege is not sufficient. Usually a user with "admin" privilege is added to a course when it is created and that user can give "admin" privilege to any other user.
Dear Colleagues,
Thanks for the replies. The reason I ask is that I'm thinking about enabling LTI authentication with Canvas. However this is a global action, so I wanted to allow instructors who don't use Canvas to use webwork too, and I thought that including the line
include("conf/authen_ldap.conf");
in course.conf for any course that is not using Canvas. Is there another easy solution for this situation?
Sincerely,
Lars.
Hi Lars,
This is a late answer and you might not have this question anymore, but you can combine the different authentication methods together so that they fall back from one to another.
For example in localOverrides.conf we have enabled:
include("conf/authen_LTI.conf");
include("conf/authen_ldap.conf");
and then we have these prioritized
$authen{user_module} = [
{ "*" => "WeBWorK::Authen::LTIAdvanced", }, #preferred authorization method
{ "*" => "WeBWorK::Authen::LDAP",}, #fallback authorization method 1
{ "*" => "WeBWorK::Authen::Basic_TheLastOption",} #fallback authorization method 2
];
The reason I found your question is because even with these settings I need to edit some of the course.conf files as some instructors use Blackboard with course level grades while others with set level grades.
There isn't really an "official" way to do this at the course level. It partially depends on whether the LTI settings will be the same for all courses on the WeBWorK server.
In order to understand how LTI is configured, a little background on WeBWorK configuration is necessary:
WeBWorK reads four configuration files in order, with the latter ones taking precedence if a setting is defined in more than one of them:
To enable LTI, there are two components to the configuration:
If your LTI configuration is going to be the same for all of the WeBWorK courses where it is going to be enabled, then you should be able to just add
include("conf/authen_LTI.conf");
to each course. You just have to make sure that you have edited that file so that it matches your LMS (in particular the consumer secret). You can also enable debugging in that file which will cause WeBWorK to tell you all of the things that the LMS is sending.
So, does the mean to edit each separate course conf file? To my knowledge, we don't actually use those, we do all configuration through the course configuration page.
Here is precisely what happens.
One piece of information is that we already have uncommented
include("conf/authen_ldap.conf"); and it is properly set up to do LDAP authentication however our institution does that. Could there be any possible conflict between these two inclusions? Given that both seem to be defining $authen{user_module} ? But I don't know much Perl.
> Seems that $external_auth had at least something to do with it.
Is it unclear what that controls? It's functionality is documented in https://github.com/openwebwork/webwork2/blob/master/conf/authen_LTI.conf.dist.
I'm inferring that now:
>If I do uncomment it, no matter what combination of options
in authen{user_module} I use, I get the message I mentioned in my
previous post.
is no longer true? Now that you have $external_auth = 0, you reach the password login screen?
> But still am not getting the LTI login attempt.
That could mean it's failing to authenticate because of not being configured correctly, and moving on to the basic password login. Have you used:
https://github.com/openwebwork/webwork2/blob/master/conf/authen_LTI.conf.dist#L12
to see the details of what the LMS is trying to send to WeBWorK?
> Now that you have $external_auth = 0, you reach the password login screen?
Correct. Actually, I just commented that line - I assume that is equivalent to =0, though I don't know Perl well enough to verify that.
> $debug_lti_parameters = 1;
Yes, I set this. But I am not seeing any info at all from the LMS. I just see the normal login page. There also isn't anything the log, since I didn't actually attempt to log in (yet). "LTI calling parameters printed to HTML page" but that assumes I actually managed to log in. And once I log in, if I try to do a homework problem, it doesn't do anything related to the LMS, it's just a normal WW page. Some of that might be because I already have a login; we've been having a devil of a time trying to get a "test student" on the Canvas side, we'll be trying that tomorrow with one of the Canvas admins (I hope!).
As a side note, I have "You are trying to launch insecure content from within a secure site (canvas). Some web browsers may prevent this content from loading." and so it always opens in a new tab/windows. That is probably a Canvas setting. Maybe that is part of the problem too?
Haha, good question! Yes, I am. And it registered properly - at first we got the error message several others have mentioned (not in this thread) but we got that sorted. (The documentation seems to be wrong in some spots as to whether you put something in the two domain/URL spaces when registering the app.)
I am hoping that the problem has something to do with our trying to use non-student accounts to log in thus far. Unless ... do you have any experience with the whole "opening a separate window" thing - could that be the problem?
In Canvas where you configure the app, there may be options for what kind of data it will send. One of these options should be something that allows it to send identifying information like the studnet's ID. I think the options are like "private", "public", and some others, and I can't recall whether "private" means share private data like user IDs or keep that kind of data private.
But have you fiddled with this?
According to these instructions https://webwork.maa.org/wiki/LTI-Advanced_Authentication#Canvas "Privacy" should be set to "Public".
I think you are talking about the "Privacy" setting in the external app configuration in Canvas. The options are "Anonymous", "Name Only", "E-Mail Only", and "Public". I believe that the only setting that will work with WeBWorK is Public, which means various identifying information (name, email, Canvas ID, SIS ID of the course, SIS ID of user, etc.) is sent to the vendor (see https://canvas.instructure.com/courses/860915/pages/how-to-configure-an-external-app-for-a-course).
Yes, we set privacy to Public as in the instructions.
I hate to ask for all this help on a hijacked thread, especially since I feel people's efforts are being wasted by my lack of knowledge about Canvas. I feel like there must be something REALLY obvious that I haven't done, like these (which sadly aren't options to fix, I don't think).
What is so weird is that it doesn't even show any attempt to create a user in any log. For instance, the course logs/login.log ONLY shows AUTH LDAP and AUTH WWDB (and OK and FAILED of course), but nothing about LTI attempts. I wouldn't even know what to look for, but at any rate the string LTI is not to be found.
Thanks to all who are offering assistance, much appreciated.
$authen{user_module} = [
{ "*" => "WeBWorK::Authen::LTIAdvanced", }, #preferred authorization method
{ "*" => "WeBWorK::Authen::LDAP",}, #fallback authorization method 1
{ "*" => "WeBWorK::Authen::Basic_TheLastOption",} #fallback authorization method 2
];
If this works, then you can remove the LTIAdvanced line from localOverrides.conf so that LTI is not enabled for all courses, and copy the $authen{user_module} block into the course.conf file for any course in which you want to enable LTI.
> If you try to enable both LDAP and LTI in localOverrides.conf by including the respective configuration files, then the last one included will override the earlier one as the only authentication method.
That is what I was missing. I had these lines, but not in the local override file, only in the LTI file! That makes a lot more sense. I didn't realize that earlier post of Andras' was referring to all the same file.
NOW I am getting nasty errors, as promised. Finally!
> Nonce Expired. Your NonceLifeTime may be too short at ...
I can look this up, as I recall seeing some stuff about it before. Hopefully soon to be resolved. Thank you!!!
If anyone is seeing this thread, I am now back at square one. We had a rather nasty malware attack in October, and did not use LTI auth since then. I'm trying to get it back up, and am baffled.
We are using WW 2.16, https:, and I have put all things ONLY in the course.conf file, which I think is okay based on everything I'm reading above. I can tell course.conf is being read, because if I change to
$external_auth=1;
we get the expected message "The course ... uses an external authentication ...". However, if I comment that line out, I get only the basic authentication option, and no log files about having tried the LTI. Immediately after the previous line, I have this:
$authen{user_module} = [
{ "*" => "WeBWorK::Authen::LTIAdvanced", }, #preferred authorization method
{ "*" => "WeBWorK::Authen::Basic_TheLastOption",} #fallback authorization method 2
];
but this just does not seem to be activated, even if I set$LTIAccountCreationCutoff = "professor";
though I'm pretty sure our LMS person is "seen" by Canvas as a student, and she gets the same things as I do.Based on the discussion earlier, since I do have
$debug_lti_parameters = 1;
Thanks for any ideas of what I forgot to plug in.
I can think of a few things to check:
I'll throw in a couple of obvious ones for completeness:
Is there something later in your configuration that could overwrite the variable setting? I can think of a couple of ways that this could happen:
Another thing to try would be to set $authen{user_module} to something else to make sure that it is being read. For example you could set
$authen{user_module} = [];
This should completely break authentication for the course. If it doesn't, then that variable is being overwritten later on. If it does, then we know that the variable is being set, and there's something else going on with LTI authentication.
Another thing to try would be to set $authen{user_module} to something else to make sure that it is being read. For example you could set
$authen{user_module} = [];
This should completely break authentication for the course. Yes, this certainly did! That was a great idea to test.Is it possible that our Canvas setup simply won't allow LTI connections of this type to "external" servers? Our Canvas instance is in the cloud, but heavily locked down, so that might be it. We are no longer allowed to use LDAP, for instance, to authenticate our WW server, which isn't administered by our main admins, though it is physically located on campus and has the correct domain name ending in edu. But I have no idea how to check if this is the problem.
I did try
$session_management_via = "key";
from another thread, but (as expected) this didn't appear to do anything useful, though I'll probably keep it just because of the Safari thread issues.
I'd be surprised if Canvas allowed you to set up an LTI link, but then silently failed when you tried to use it because you weren't allowed.
If you have $debug_lti_parameters=1, then you should see a warning message any time LTI authentication is attempted, even if it's not successful. I would expect this to occur even if Canvas isn't sending sufficient information to successfully log in. I'm at a loss as to why this isn't happening.
My next step in troubleshooting would be to try initiating an LTI connection from something other than Canvas. If you try this and get the warning messages then it's a safe bet that the issue is something with the Canvas configuration.
I found the following simple LTI launch script. You can put that file on a web server with php, and change the launch_url to your WeBWorK server. Even if the authentication is unsuccessful you should still see the warning messages with the LTI parameters that were passed.
Thank you very much for the suggestion. I'll have to wait until next term for it, I think (going with script-created accounts as in the not-too-distant past), but hopefully we can figure it out in 2023!
(Or perhaps LTIGradeOnSubmit, but I don't think that I have that set yet anyway.)
I am not sure how it works on canvas, but on Blackboard the way I tested the new account creation and the bridge between Blackboard and WeBWorK is the following way:
> If I do uncomment it, no matter what combination of options in authen{user_module} I use, I get the message I mentioned in my previous post.
What is your setting for $external_auth?
https://github.com/openwebwork/webwork2/blob/master/conf/authen_LTI.conf.dist#L53
You can can also see related error messages (as one method fails, and another is successful) in the logs/login.log file of the course.
Hi Andras,
Thanks so much for the information. I had already tried your suggestion, and I get this error message after enabling LDAP as fallback authentication method:
Failed to initialize course environment: Could not evaluate global environment file /opt/webwork/webwork2/conf/defaults.config: Include file /opt/webwork/webwork2/conf/localOverrides.conf did not return a true value. at (eval 641) line 16. at /opt/webwork/webwork2/lib/WeBWorK.pm line 233.Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xe" for details.
Do you know what the errors mean?
Sincerely,
Lars.
You included the configuration files authen_LTI.conf and authen_ldap.conf into localOverrides.conf, which is included into defaults.config.
There must be something wrong with the settings in either the authen_LTI.conf or the authen_ldap.conf file.
Can you check the apachectl messages in /var/log/syslog ?
Hi Andras,
Thanks for your reply.
No, I didn't move any settings from the authen_LTI and authen_ldap files into localOverrides. I only configured the three files according to your directions. I have attached my config files (concatenated into a single file - moodle only allows me to attach a single file). I couldn't find anything relevant in my apache log files.
On my system, ldap authentication works perfectly by itself. LTI authentication works perfectly by itself. But I can't make them work together.
Sincerely,
Lars.
Hi Lars,
What I meant is that these lines "include" the files automatically into localOverrides.conf
include("conf/authen_LTI.conf");
include("conf/authen_ldap.conf");
The config files have these parts repeated in both of them
$authen{user_module} = [ ...
Can you try to comment them out so that they are only used in the localOverrides.conf?
Hi Andras,
I tried with and without the $authen{user_module} = [ ... line commented out in authen_ldap.conf (and the $authen{user_module} = [ ... enabled in authen_LTI.conf). The error was he same in either case, the one included in my earlier post.
Sincerely,
Lars.
I have $authen{user_module} = [ ... only in the localOverrides.conf file and after the two include lines.
Hi again,
So I thought I had this working, but not quite. Both LTI and ldap authentication now works together for both students and professor, but when this is set up, after login through ldap, access to problem sets only works for the professor. If after student logs in with ldap, the student clicks on a problem set, this error pops up:
The selected problem set (Post,v1) is not a valid set for studenta:
You must use your Learning Managment System (E.G. Blackboard, Moodle, Canvas, etc...) to access this set. Try logging in to the Learning Managment System and visiting the set from there.
A professor does not get this error.
How do I allow students to get to the problem sets when they login with ldap?Sincerely,
Lars.
This happens to my students when I have in auth_LTI.conf the setting $LTIGradeMode = "homework"; enabled instead of $LTIGradeMode = "course";
See https://webwork.maa.org/wiki/LTI-Advanced_Grading
This can also be changed in individual course.conf files.
In order for per-homework grade passback to work, WeBWorK needs an assignment specific lis_result_sourcedid which it will only get when a student uses the homework specific LTI link the first time. Once that value is in the database - the student can access the assignment using alternative methods. Thus, using $LTIGradeMode = "homework"; together with alternative authentication methods will work if students are told to use the per-assignment link at least once.
The last line of several conf files must be something like
1; #final line of the file to reassure perl that it was read properly.
as the code which loads it tests for a true Perl return value to confirm it loaded OK.
The error message you got is caused by the test for this in
lib/WeBWorK/CourseEnvironment.pm failing.