I am currently working on getting students to go from a course page on Moodle to my webwork HomeworkSet.
On moodle I created a External Tool for my course page. In the settings of the external tool I configured the following;
Launch: New Window
Consumer key: <myconsumerkey>
Shared Secret: <secretsharedkey>
ToolURL: <URL to the assignment >
Share Launchers name with tool (on)
Share launcher's email with the tool (on)
Accept grades from the tool (on)
-------------------------------------------------------------------
I have a separate account on moodle to test as a student. So I sign in (using incognito) to my student account. I then use the external tool link to get to the assignment.
At this point as the student I get to the homeworkset called "KelsettestSet" which has 1 problem in it. I click on the problem and it takes me to the CAS login screen.
****Now I must mention, I am using both LTI and CAS for this. LTI for students going from moodle to webwork. CAS is for the instructors seeing as they will go to the webwork site directly and login to their course.*****
In theory the students shouldn't need to see the CAS screen.
-----------
My CAS/LTI config file is below:
#!perl
#############################################################################
# authen_LTI.conf
# Configuration for using LTI authentication.
# To enable this file, uncomment the appropriate lines in localOverrides.conf
#############################################################################
# Set debug_lti_parameters to 1 to have LTI calling parameters printed to HTML page for
# debugging. This is useful when setting things up for the first time because
# different LMS systems have different parameters
$debug_lti_parameters = 0;
# To get more information on passing grades back to the LMS enmass set debug_lti_grade_passback
# to one. And set the LTIMassUpdateInterval to 60 (seconds).
$debug_lti_grade_passback = 0;
# This will print into the apache log the success or failure of updating each user/set.
# If the set has "no lis_source_did" then that set hasn't been assigned, or the user is an instructor
# and not a student.
# Setting both debug_lti_parameters and debug_lti_grade_passback will cause the full request and
# response between the LMS and WW to be printed into apache error log file for each
# user/set update of the grade.
# The switches above can be set in course.conf to enable debugging for just one course.
# If you want even more information enable the debug facility for SubmitGrade.pm in
# the WeBWorK::Constants file.
# This will print extensive debug messages for all courses.
# This first section enables LTI authentication.
# Failover to Basic_TheLastOption is necessary to authenticate with
# cookie keys.
###################
$authen{user_module} = [
{ "*" => "WeBWorK::Authen::LTIAdvanced", }, #preferred authorization method
{ "*" => "WeBWorK::Authen::CAS", }, #secondary direct webwork authorization method (professors)
{ "*" => "WeBWorK::Authen::Basic_TheLastOption",} #fallback authorization method
];
# If the preferred module is an external authentication
# module but the sequence includes an internal authentication
# system, e.g., Basic_TheLastOption, then the following line
# must be commented out.
# If it is uncommented and the value = 1,
# then, if the authentication sequence reaches
# Basic_TheLastOption, then WeBWorK::Login
# will display a screen directing the user
# back to an external authentication system.
# This prevents you from attempting to login in to WeBWorK directly.
#$external_auth=1;
# NOTE: If external authentication is disabled
# then you should probably also prevent students
# from changing their passwords (because they cant use them).
# To do this ucomment the following
# $permissionLevels{change_password} = "ta";
################################################################################
# CAS Options (taken from authen_CAS.conf)
################################################################################
$authen{cas_options} = {
# Options to pass to the AuthCAS module.
# Note that this is (plain) AuthCAS, not Apache::AuthCAS
# or Apache2::AuthCAS.
# You need at least casUrl and CAFile; others can be set as well.
AuthCAS_opts => {
# URL of CAS server. Edit the host below.
casUrl => 'https://MY-SCHOOLS-CAS-SERVER', #e.g. 'https://auth.$
#loginPath => 'https://MY-SCHOOLS-CAS-SERVER',
#logoutPath => 'https://MY-SCHOOLS-CAS-SERVER',
#serviceValidatePath => 'https://MY-SCHOOLS-CAS-SERVER',
# Path of certificate file for CAS server.
CAFile => '', #e.g. '/etc/pki/tls/certs/ca-bundle.crt',
},
# There are no options specific to CAS at this time. If there were,
# though, they would go here.
# For debugging:
#su_from => '8315',
su_to => '999999',
};
################################################################################
# LTI Basic parameters
################################################################################
################################################################################
# LTI Preferred Source of Username
################################################################################
# If both lis_person_sourcedid (or one of its variants)
# and lis_person_contact_email_primary are present,
# then one needs to state which one is preferred
# as the WeBWorK username.
# The considerations are (1) ensuring that usernames
# are unique and (2) being as compatible as possible with the practices
# of the institutions that are being served in a site.
# If a site is only being used be students from a single
# institution and the value lis_person_sourcedid is
# unique across the population and matches the logon username
# at that institution, then lis_person_sourcedid is
# probably the better choice.
# On the other hand, if a site is serving a population
# from several institutions and lis_person_sourcedid is not
# necessarily unique across the population, then
# lis_person_contact_email_primary is the better choice.
# Because the WeBWorK username must be unique across
# the population served by a site, the default if
# neither line is uncommented will be the value of
# lis_person_contact_email_primary.
# NOTE: Even if a course management system sends
# one of the common misspellings of "lis_person_sourcedid", i.e.,
# lis_person_sourced_id, lis_person_source_id, and
# lis_person_sourceid, one must nevertheless use
# the correct spelling here, i.e. "lis_person_sourcedid".
$preferred_source_of_username = "lis_person_sourcedid";
#$preferred_source_of_username = "lis_person_contact_email_primary";
# Some LMS systems, Blackboard in particular, do not send lis_person_sourcedid
# if you enable this flag and have $preferred_source_of_username set to
# lis_person_contact_email_primary, then webwork will strip off the address
# portion of the email and just use the username.
#$strip_address_from_email = 1;
################################################################################
# LTI Preferred source of Student Id
################################################################################
# If preferred_source_of_student_id is not set, WeBWorK will look in the LTI
# parameter 'custom_student_id.' If preferred_source_of_student_id is set, then
# WeBWorK will look in the LTI parameter specified below. This parameter may be
# dependendent on the LMS. E.G., In D2L, student_id is stored in OrgDefinedId and
# the corresponding LTI parameter is called ext_d2l_orgdefinedid.
#$preferred_source_of_student_id = "ext_d2l_orgdefinedid";
################################################################################
# LTI Basic Authentication Parameters
################################################################################
# This "shared secret" is entered in the LMS request form and needs to be
# match the entry here. This is used to validate all requests between the
# LMS and WeBWorK
# You should choose your own secret word for security and should treat it
# like a password.
$LTIBasicConsumerSecret = "MY-SECRET"; #This must be set
#$LTIBasicConsumerSecret = "MY-SECRET"; #This must be set
# The purpose of the LTI nonces is to prevent man-in-the-middle attacks.
# The NonceLifeTime (in seconds) must be short enought to prevent
# at least casual man-in-the-middle attacks but
# long enough to accommodate normal server and networking delays
# (and perhaps non-synchronization of server time clocks).
#
$NonceLifeTime=60; # in seconds
# WeBWorK will automatically create users when logging in via the LMS for the
# first time. If the following flag is enabled then it will also keep the
# user demographic data up to date with the LMS. If a users information change
# in the LMS then it will change in WeBWorK. However, any changes to the
# student data via WeBWorK will be overwritten the next time the student
# logs in.
$LMSManageUserData=1;
# NOTE: If mange user data is enabled then you should probably also
# prevent students from changing their email because the changes
# will be overwritten. To do this ucomment the following
$permissionLevels{change_email} = "ta";
# This allows you to override the URL that Oauth will use to validate the
# authentication. This is important if you have some sort of setup (e.g. load
# distributing) where the path in the LMS does not match the path that ends up
# in the webwork page
#$LTIBasicToThisSiteURL = "";
################################################################################
# Authorization system LTI: LMS Grade Passback
################################################################################
# WeBWorK can automatically report grades back to your LMS. However the
# system is reasonably restrictive. When you create an LTI link in your
# LMS you can choose to have that LTI link have a grade associated to it.
# WeBWorK can report back a single percentage as the "grade" for that link.
# There are two modes under which this can occur.
#
# Single Course Grade Mode: $LTIGradeMode = "course";
#
# In this mode you create a single Link/Assignment which points to your
# WeBWorK Course address. E.G. In Blackboard
# Name: WeBWorK
# URL: https://webwork.university.edu/webwork2/CourseName
# Check Yes: This link is to a Tool Provider
# Enable Evaluation: Yes
# Points Possible: 100
# Students will receive a LMS grade associated to the Link/Assignment
# which is determined by their percentage total homework grade in WeBWorK.
# This total homework grade is the same as the grade that is reported on the
# grades page. You can change the weight of sets by altering the weight of
# the problems in the set.
#
# Individual Homework Grade Mode: $LTIGradeMode = "homework";
#
# In this mode you create a single Link/Assignment for *every* homework set in
# the course. The address should be the address of that set in the Course.
# E.G. in Blackboard
# Name: Set Name
# URL: https://webwork.university.edu/webwork2/CourseName/SetName
# Check Yes: This link is to a Tool Provider
# Enable Evaluation: Yes
# Points Possible: 100
# Students will receive a grade for each Link/Assignment which is determined
# by their percentage homework grade on the Set which the Link/Assignment
# points to. Students need to use the Link/Assignment in the LMS at least once
# to enable grade passback. In particular when working in this mode it is
# recommended that you only allow students to log in via the LMS.
#
# Note: For both of these modes only the grades are passed back. In
# particular nothing else about the Link/Assignment in the LMS and the
# homework set in WeBWorK is syncronized. In particular the total number of
# points/problems, the due dates, the open dates are not kept in sync
# automatically.
$LTIGradeMode = "course";
#$LTIGradeMode = "homework";
# When set this variable sends grades back to the LMS every time a user
# submits an answer. This keeps students grades up to date but can be
# a drain on the server.
#$LTIGradeOnSubmit = 1;
$LTIGradeOnSubmit = 0;
# The system periodically updates student grades on the LMS. This
# variable controls how often that happens. Set to -1 to disable.
#$LTIMassUpdateInterval = 86400; #in seconds
# For testing:
#$LTIMassUpdateInterval = 60; #in seconds
$LTIMassUpdateInterval = 3600; #in seconds
################################################################################
# Authorization system LTI: LMS Roles Mapped to WeBWorK Roles
################################################################################
# You may need to customize this hash to take into account the roles
# that are used in your LMS. Set the debug_lti_parameters flag to see
# what roles are being reported to WeBWorK by your LMS
%LMSrolesToWeBWorKroles = (
"librarian" => "guest",
"observer" => "guest",
"visitor" => "guest",
"Guest" => "guest",
"Designer" => "professor",
"instructor" => "professor",
"Instructor" => "professor",
"Faculty" => "professor",
"Teacher" => "professor",
"Student" => "student",
"Learner" => "student",
"student" => "student",
"AI/TA" => "ta",
"TA" => "ta",
"Teaching Assistant" => "ta",
"Teaching Assistant (TA)" => "ta",
"Non-editing teacher" => "ta",
"Grader" => "ta",
);
# For security reasons accounts with high permissions should not be auto
# created via LTI requests. Set this variable to "professor" if you want
# professor accounts to be created automatically
$LTIAccountCreationCutoff = "ta";
#$LTIAccountCreationCutoff = "professor";
################################################################################
# Local routines
################################################################################
# These local routines can be used to modify and override various elements of
# the authentication process.
################################################################################
# Local routine to modify users
################################################################################
# When users are added to the system WeBWorK will do its best to fill out
# user information. However, institutions can add code to the following
# routine to set fields not normally set by WeBWorK. E.G. The student ID
# field.
#$LTI_modify_user = sub {
# # The self object from LTIAdvanced.pm
# my $self = shift;
# # The user object to be modified
# my $user = shift;
#
# # Parse context_id for additional information. E.G.
# my @course_id=split /-/, $self -> {"context_id"};
# $user->{"section"} = $course_id[4];
# };
################################################################################
# Local routine to modify user sets
################################################################################
# When users are added to the system they are also assigned all visible sets
# This routine can be used to modify the sets before they are assigned. E.G.
# extend due dates based off the number of problems students have to do
#$LTI_modify_user_set = sub {
# # The self object from LTIAdvanced.pm
# my $self = shift;
# my $globalSet = shift;
# # The userSet object to be modified
# my $userSet = shift;
# my $numberOfSetsAssigned = $self->{numberOfSetsAssigned};
# my $daysPerSetMakeup = 2;
# my $reasonableNumberOfDays = $numberOfSetsAssigned*$daysPerSetMakeup +1;
# if ($reasonableNumberOfDays < 2) {$reasonableNumberOfDays = 2;}
# my $niceDueTime = $globalSet->due_date + $reasonableNumberOfDays*86400;
# my $niceAnswerTime = $niceDueTime + 600;
# $userSet->due_date($niceDueTime);
# $userSet->answer_date($niceAnswerTime);
#};
1; #final line of the file to reassure perl that it was read properly.
----------------------------------------------------------------------
NOTE: I have set my course to assignment mode in the course.conf file.