Installation

debug_lti_parameters turned on but don't see anything

debug_lti_parameters turned on but don't see anything

by Lorenzo Ng -
Number of replies: 17

hello folks

Trying to do sso/ssi between moodle and webwork 2.18 on redhat 8.9 using lti 1.1 and maybe later, lti 1.3

Does not seem to work so i turned on the debug lti parameter to 1

debug_lti_parameters = 1;

rebooted the server but nothing shows on the webwork login screen like it should.. why does it not show up? i want to see what is passed to use as its user login name.. they can login via ldap no problem but it should automatically log them in when they click on the Moodle resource to their WeBWork course.. was working on version but not in 2.18 

thoughts?




In reply to Lorenzo Ng

Re: debug_lti_parameters turned on but don't see anything

by Alex Jordan -

This might mean that the link you are clicking on in Moodle is just a plain old regular link to the WeBWorK course. As opposed to an External Learning Tool link (or whatever the Moodle-specific terminology is for an LTI link). Can you confirm that the link in Moodle is not just a regular link?

In reply to Alex Jordan

Re: debug_lti_parameters turned on but don't see anything

by Lorenzo Ng -

Yes it is an external LTI tool


maybe i should check the moodle external lti tool and try again? but read it a million times

the strange thing is that I contacted another school and both my authen_lti.conf and authen_LTI_1_1.conf are the same! 

his works but not mine :-(



In reply to Lorenzo Ng

Re: debug_lti_parameters turned on but don't see anything

by Glenn Rice -

Did you also check your localOverrides.conf file to see that the authen_LTI.conf file is included in that file?

In reply to Glenn Rice

Re: debug_lti_parameters turned on but don't see anything

by Lorenzo Ng -

absolutely... in fact authen_LTI is using LTI 1.3..  both 1.1 and 1.3 behave the same..

I've got the all the data I need and followed the LTI 1.3 instructions to a tee

https://webwork.maa.org/wiki/LTI-Advanced_Authentication#With_Moodle (see to show I followed the example) :-)

nothing.. strange .. 

the login username is email and email domain stripped off..

I'm starting to think either a package is missing (check_....pl was fine) or some sort of port/protocol is being blocked) that passes these values to webwork from Moodle (4.1)

Maybe I'll try and upgrade moodle and see

Lawrence



Attachment Admin1.png
In reply to Glenn Rice

Re: debug_lti_parameters turned on but don't see anything

by Lorenzo Ng -
You might have answered this from a previous post …


LTI 1.3 is a completely different authentication method than LTI 1.1. LTI 1.3 was added in the 2.18 release of WeBWorK. So if you were able to get LTI authentication to work for 2.16, then it was LTI 1.1. If the LMS is configured for LTI 1.1, then you will need to use that instead. The configuration is much the same, except the variables are all in authen_LTI_1_1.conf and are all prefixed with $LTI{v1p1}.

If you really want to use LTI 1.3, then you will need administrative access to your Moodle instance. Note that you won't get much of debugging information in the browser when you turn on debugging due to the way that LTI 1.3 works. So you will need to check the logs/webwork2.log file.”
In reply to Lorenzo Ng

Re: debug_lti_parameters turned on but don't see anything

by Lorenzo Ng -
I checked the webwork2.log and nothing in debugging there ... in fact both LTI 1.1 and LTI 1.3 debugging shows nothing :-(

$> tail -n 50  webwork2.log | more

[2024-01-31 09:07:17.92773] [141937] [info] Worker 153279 stopped
[2024-01-31 09:07:17.92777] [141937] [info] Worker 153280 stopped
[2024-01-31 09:07:17.92782] [141937] [warn] Stopping worker 150468 immediately
[2024-01-31 09:07:17.92784] [141937] [warn] Stopping worker 141951 immediately
[2024-01-31 09:07:17.92786] [141937] [warn] Stopping worker 153758 immediately
[2024-01-31 09:07:17.92788] [141937] [warn] Stopping worker 149695 immediately
[2024-01-31 09:07:17.92790] [141937] [warn] Stopping worker 152991 immediately
[2024-01-31 09:07:17.94571] [141937] [info] Worker 150468 stopped
[2024-01-31 09:07:17.94583] [141937] [warn] Stopping worker 141951 immediately
[2024-01-31 09:07:17.94586] [141937] [warn] Stopping worker 153758 immediately
[2024-01-31 09:07:17.94588] [141937] [warn] Stopping worker 149695 immediately
[2024-01-31 09:07:17.94590] [141937] [warn] Stopping worker 152991 immediately
[2024-01-31 09:07:17.96571] [141937] [info] Worker 141951 stopped
[2024-01-31 09:07:17.96583] [141937] [info] Worker 149695 stopped
[2024-01-31 09:07:17.96588] [141937] [info] Worker 152991 stopped
[2024-01-31 09:07:17.96592] [141937] [info] Worker 153758 stopped
[2024-01-31 09:07:17.96597] [141937] [info] Manager 141937 stopped
[2024-01-31 09:07:42.83760] [1044] [info] WeBWorK server is starting
[2024-01-31 09:07:42.84149] [1044] [info] WeBWorK root directory set to /opt/webwork/webwork2
[2024-01-31 09:07:42.84154] [1044] [info] PG root directory set to /opt/webwork/pg
[2024-01-31 09:07:42.84157] [1044] [info] The webwork url on this site is https://testwebwork.outsite.com/webwork2
[2024-01-31 09:07:42.84160] [1044] [info] webwork_server_admin_email for reporting bugs has been set to elsupport@vcc.ca in site.conf
[2024-01-31 09:07:43.20112] [1044] [info] Listening at "http://*:8080"
[2024-01-31 09:07:43.20605] [3255] [info] Manager 3255 started
[2024-01-31 09:07:43.22322] [3256] [info] Worker 3256 started
[2024-01-31 09:07:43.22492] [3257] [info] Worker 3257 started
[2024-01-31 09:07:43.23970] [3258] [info] Worker 3258 started
[2024-01-31 09:07:43.24230] [3259] [info] Worker 3259 started
[2024-01-31 09:07:43.24392] [3260] [info] Worker 3260 started
[2024-01-31 09:07:43.24549] [3261] [info] Worker 3261 started
[2024-01-31 09:07:43.24708] [3262] [info] Worker 3262 started
[2024-01-31 09:07:43.24861] [3263] [info] Worker 3263 started
[2024-01-31 09:07:43.25017] [3264] [info] Worker 3264 started
[2024-01-31 09:07:43.25166] [3255] [info] Creating process id file "/run/webwork2/webwork2.pid"
[2024-01-31 09:07:43.25355] [3271] [info] Worker 3271 started
[2024-01-31 09:07:43.25481] [3270] [info] Worker 3270 started
[2024-01-31 09:07:43.25621] [3269] [info] Worker 3269 started
[2024-01-31 09:07:43.25747] [3268] [info] Worker 3268 started
[2024-01-31 09:07:43.25866] [3267] [info] Worker 3267 started
[2024-01-31 09:07:43.26010] [3266] [info] Worker 3266 started
[2024-01-31 09:07:43.25176] [3265] [info] Worker 3265 started
[2024-01-31 09:07:43.26152] [3272] [info] Worker 3272 started
[2024-01-31 09:07:43.26271] [3273] [info] Worker 3273 started
[2024-01-31 09:07:43.26388] [3274] [info] Worker 3274 started
[2024-01-31 09:07:43.26501] [3275] [info] Worker 3275 started
[2024-01-31 09:07:43.26618] [3276] [info] Worker 3276 started
[2024-01-31 09:07:43.26734] [3277] [info] Worker 3277 started
[2024-01-31 09:07:43.26850] [3278] [info] Worker 3278 started
[2024-01-31 09:07:43.26993] [3279] [info] Worker 3279 started
[2024-01-31 09:07:43.27100] [3280] [info] Worker 3280 started


in the log timing.log, I only have one entry, which is the one I just tested just now (January 31, 2024)

[Wed Jan 31 09:11:57 2024] 3264 1706721117 - [/webwork2/WhoDat-for-Gerbils] [runTime = 0.262 sec sql_single]


In reply to Lorenzo Ng

Re: debug_lti_parameters turned on but don't see anything

by Glenn Rice -
Since you are not seeing anything in the webwork2 logs, the LTI login requests are not being received at all from Moodle. So either the link has not been entered correctly in Moodle, or something is blocking the request from going through.
In reply to Glenn Rice

Re: debug_lti_parameters turned on but don't see anything

by Danny Glin -

The other possibility is that LTI authentication is not enabled on your server.  The $authen{user_module} variable should be set in the LTI conf file.  Make sure that it is not being overwritten later on in the configuration.

In reply to Lorenzo Ng

Re: debug_lti_parameters turned on but don't see anything

by Lorenzo Ng -

So weird... still don't understand why this is happening..

the webwork server is exposed to the internet and now I see on the url bar the login url

https://testwebwork.oursite.com/webwork2/ltiadvantage/login

and not the url of the course and it does show the right course in the login page

nothing in the footer

the server name is oursite.com and in the /var/www/html, I had to do a redirect to oursite.com/webwork2 in the index.html page 

using LTI 1.3 by the way ...

so strange .. it works with LTI 1.1 on another server and tried LTI 1.1 on this one and it still fails! 

In reply to Lorenzo Ng

Re: debug_lti_parameters turned on but don't see anything

by Glenn Rice -

If you are using LTI 1.3, then that is what you should see for the first url that comes from Moodle.  The page that loads will have a hidden form in it that is automatically submitted by javascript.  Can you inspect the page source, and see that the hidden form is there?

A redirect from an index.html file in /var/www/html most likely will not work with either version of LTI, or for webwork2 version 2.18 at all.  How are you serving the webwork2 app?  Are you serving it directly, or are you proxying via apache2?

I recommend that you try to get LTI 1.1 working first if you have used that before.  LTI 1.3 is more challenging.

In reply to Glenn Rice

Re: debug_lti_parameters turned on but don't see anything

by Lorenzo Ng -

proxying via apache

the redirect works with 2.16 and lti 1.1 though

how can I make outsite.com/webwork2 as the landing page without redirect?

if I type in oursite.com, it just goes to apache default page

In reply to Lorenzo Ng

Re: debug_lti_parameters turned on but don't see anything

by Glenn Rice -
If you type in http://oursite.com it should go to the root url for your server. That would be the apache2 default page if you don't have it set up to show something else. However, if you have the proxy set up correctly, then when you enter http://oursite.com/webwork2 it should open the webwork course list page without a redirect. What do you have in your apache2 configuration files? Have you copied the webwork2.apache2.4.dist.conf file, and linked to it correctly in /etc/apache2/conf-enabled? Also, what do you have in your copy of the dist file?

(Of course you would be using https in the above links if you have SSL certificates set up.)
In reply to Glenn Rice

Re: debug_lti_parameters turned on but don't see anything

by Lorenzo Ng -

Both are correct.. 

if you go to oursite.com, just show apache page

oursite.com/webwork2 has the list of courses shown

went back to LTI 1.1 and same non-login no debug non-response shown even when debug_lti is set to "1" in localOverrides.conf

authen_lti.conf is set to use "conf/authen_LTI_1_1.conf"

and secretpassword is set ...

it does make me think.. what should t $preferred_source_of_username be set to?

our login is XXXXXX@ourschool.com

I copied what was working on WW 2.16 settings to WW 2.18 for LTI 1.1 and does not work, which is driving us wild LOL

webwork2.conf in /etc/httpd/conf.d/

webwork2.conf -> /opt/webwork/webwork2/conf/webwork2.apache2.4.conf


# Uncomment the following lines to allow access to show-source.cgi.  This allows the "show source" button that is added
# by the "source.pl" macro to work for demonstration "courses".  It requires that a show-source.cgi script be customized
# and placed in the courses html directory.  You will also need to enable the apache2 cgi module with `sudo a2enmod cgi`
# for this to work.  Note that if you have the mpm_event module enabled instead of mpm_worker, then you will need the
# cgid module instead.  Apache2 will automatically select this module if the given command is used.  The "show source"
# button is most useful for webwork "courses" used to train new authors.  It is not desirable to expose the code of
# regular homework questions to students.
#<DirectoryMatch /opt/webwork/courses/[^/]*/html/>
#       Options -MultiViews +SymLinksIfOwnerMatch
#       AllowOverride None
#       Require all granted
#</DirectoryMatch>
#ScriptAliasMatch /webwork2_course_files/([^/]*)/show-source.cgi/(.*) /opt/webwork/courses/$1/html/show-source.cgi/$2
#ProxyPassMatch /webwork2_course_files/([^/]*)/show-source.cgi/(.*) !
# Note that if $webwork_url in site.conf is changed, then /webwork2
# should be changed below to match.
<Proxy /webwork2/*>
        Require all granted
</Proxy>
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /webwork2 http://localhost:8080/webwork2 keepalive=On
ProxyPassReverse /webwork2 http://localhost:8080/webwork2
ProxyPass /webwork2/* http://localhost:8080/webwork2/ keepalive=On
ProxyPassReverse /webwork2/* http://localhost:8080/webwork2/
<Location /webwork2/>
       RequestHeader set X-Forwarded-Proto "https"
       # RequestHeader set X-Forwarded-Proto "http"
</Location>
# Note that if $webwork_htdocs_url in site.conf is changed, then /webwork2_files
# should be changed below to match.
<Proxy /webwork2_files/*>
        Require all granted
</Proxy>
ProxyRequests Off
ProxyPass /webwork2_files http://localhost:8080/webwork2_files keepalive=On
# Note that if $pg_htdocs_url in site.conf is changed, then /pg_files
# should be changed below to match.
<Proxy /pg_files/*>
        Require all granted
</Proxy>
ProxyRequests Off
ProxyPass /pg_files http://localhost:8080/pg_files keepalive=On
# Note that if $webwork_courses_url in site.conf is changed, then /pg_files
# should be changed below to match.
<Proxy /webwork2_course_files/*>
        Require all granted
</Proxy>
ProxyRequests Off
ProxyPass /webwork2_course_files http://localhost:8080/webwork2_course_files keepalive=On




In reply to Lorenzo Ng

Re: debug_lti_parameters turned on but don't see anything

by Glenn Rice -
Have you deleted the redirect in the index.html file in /var/www/html and it still goes to the webwork course list when you enter http://oursite.com/webwork2?  If that redirect is what is taking you to the course list, webwork2 in general will not function as it should.  It needs to be the apache2 proxy that does the redirection.

You say you have "$debug_lti_parameters = 1;" in localOverrides.conf.  Do you have "$debug_lti_parameters = 1;" also in authen_LTI.conf?  I recommend that you delete the line in localOverrides.conf, and set it instead in authen_LTI.conf.  The one in localOverrides.conf could be overridden by the one in authen_LTI.conf if it is set before authen_LTI.conf is loaded, and it really shouldn't be set in localOverrides.conf anyway.
In reply to Glenn Rice

Re: debug_lti_parameters turned on but don't see anything

by Lorenzo Ng -

yes.. that index.html is no longer there and when forcibly putting that file in, would result in a 404 page not found, which is good

the lti debug in localOverrides.conf was just a test... back to usual state

how can I recheck my apache proxy settings

what should $preferred_source_of_username be set to? would that be the key if I chose the wrong one?



In reply to Glenn Rice

Re: debug_lti_parameters turned on but don't see anything

by Lorenzo Ng -

My authen_LTI.conf file


#!perl
$debug_lti_parameters = 1;
$debug_lti_grade_passback = 0;
################################################################################################
# Authentication settings
################################################################################################
# This section enables LTI authentication.  If a course uses LTI 1.1 (see $LTIVersion below),
# then the LTIAdvanced module will be used.  If a course uses LTI 1.3 (see $LTIVersion below),
# the LTIAdvantage will be used.  If you know a site will not use one or the other, it can be
# commented out. Failover to Basic_TheLastOption is necessary to authenticate with cookie keys.
$authen{user_module} = [
        { '*' => 'WeBWorK::Authen::LTIAdvantage' },          # first try LTI 1.3
        { '*' => 'WeBWorK::Authen::LTIAdvanced' },           # next try LTI 1.1
        { '*' => 'WeBWorK::Authen::Basic_TheLastOption' }    # fallback authorization method
];
# Include configurations.  You must uncomment at least one of the following. You may uncomment
# both if the site may be using both LTI 1.1 and 1.3 in different courses. After uncommenting
# the LTI_1_x line, you must copy the file authen_LTI_1_x.conf.dist to authen_LTI_1_x.conf and
# then edit that file to fill in the settings for LTI_1_x.
#include('conf/authen_LTI_1_1.conf');
include('conf/authen_LTI_1_1.conf');
$LTIBasicConsumerSecret = "SecretPassword";
# This is the default LTI version that will be used for the site.  This must be 'v1p1' for LTI
# 1.1 authentication, 'v1p3' for LTI 1.3 authentication, or '' to disable LTI authentication.
# A course may override this setting to use the other version of LTI authentication or to
# disable LTI authentication for the course.
$LTIVersion = 'v1p1';
$LTIAccountCreationCutoff = 'ta';
$LMSManageUserData = 1;
$external_auth = 0;
$permissionLevels{change_password} = 'ta';
################################################################################################
# Authorization system LTI:  LMS Grade Passback
################################################################################################
$LTIGradeMode = '';
#$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;
# If CheckPrior is set to 1 then the current LMS grade will be checked first, and if the grade
# has not changed then the grade will not be updated.  This is intended to reduce changes to LMS
# records when no real grade change occurred.  It requires a 2 round process, first querying the
# current grade from the LMS and then when needed making the grade submission.
$LTICheckPrior = 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
################################################################################################
# Add an 'LTI' tab to the Course Configuration page
################################################################################################
@LTIConfigVariables = (
        #'LTI{v1p1}{LMS_name}',
        #'LTI{v1p3}{LMS_name}',
        #'LTI{v1p1}{LMS_url}',
        #'LTI{v1p3}{LMS_url}',
        #'external_auth',
        #'LTIGradeMode',
        #'LMSManageUserData',
        #'debug_lti_parameters'
);
1;    # final line of the file to reassure perl that it was read properly.



In reply to Lorenzo Ng

Re: debug_lti_parameters turned on but don't see anything

by Glenn Rice -

Your authen_LTI.conf file does have problems.  You do not have "include('conf/authen_LTI_1_3.conf');" anywhere.  If you are trying to use LTI 1.3, then you need that.  In fact if you have the "{ '*' => 'WeBWorK::Authen::LTIAdvantage' }" line uncommented, then you you should have that inclusion in the file even if you are not using LTI 1.3.

Make sure that you don't remove the line that says "include('conf/authen_LTI_1_1.conf');".  Both inclusions should be in the file with what you have in the "$authen{user_module}".

If you are trying to use LTI 1.3, then you also need $LTIVersion set to be 'v1p3'.

Once you get debugging working, then you can inspect the LTI parameters that are sent, and choose the one that you want to use for the preferred source of username.  For now, set that to 'email' in authen_LTI_1_3.conf.

Note that we have office hours every Monday from 4 to 6 pm EST.  Alex, Danny, and I will be there to help.  The link for the Zoom meeting is https://us02web.zoom.us/j/7863786631?pwd=RXhRcGxDMmZJRDcvN1lUQStkbEJjZz09.  Perhaps you could join that meeting next Monday, and we can talk about this?