I have created a pull request that does what I believe is needed to fix the issues reported here. Since I can't test the code, I offer no guarantees though. If you could test this and see if it fixes the issue, that would be extremely helpful. The hotfix pull request to main is https://github.com/openwebwork/webwork2/pull/2609.
Hello,
I have tested it. The csrf_token error is gone.
But now I get others.
--> template ContentGenerator/Login.html.ep line 12
What I did to generate the attached logs:
Clicks: Frontpage --> Course "test1" --> Problem Editor --> Library Browser --> selected something from Subject: --> View Problems
On Site Errors:
Problem Editor
--> Rendering error: Authentication failed. Log in again to continue.
Library Browser
- selected something from Subject:
--> /webwork2/instructor_rpc
Authentication failed. Log in again to continue.
- View Problems
--> Warning: There may be something wrong with this question. Please inform your instructor including the warning messages below.
The course test1 uses an external authentication system (). Please return to that system to access this course.
WeBWorK Warnings
WeBWorK has encountered warnings while processing your request. If this occurred when viewing a problem, it was likely caused by an error or ambiguity in that problem. Otherwise, it may indicate a problem with the WeBWorK system itself. If you are a student, report these warnings to your professor to have them corrected. If you are a professor, please consult the warning output below for more information.
Warning messages
Use of uninitialized value in hash element at template ContentGenerator/Login.html.ep line 12.
Use of uninitialized value in hash element at template ContentGenerator/Login.html.ep line 12.
Request information
Time Tue Oct 22 09:22:49 2024
Method POST
URI /webwork2/test1/instructor/setmaker
Yeah, I expected that rpc calls would fail.
Looking at the Shibboleth code, I see that even prior to the recent authentication renovation, Shibboleth was rife with security vulnerabilities.
Unfortunately, unless someone has time to work closely with me on this Shibboleth is a lost cause. The attempts that have been made to fix Shibboleth have been done by individuals that really don't know how webwork2's authentication works. As such, they get some of the bare bones functionality working, but don't get the complete package working and leave security vulnerabilities open.
Can I ask what you mean by work with you closely? I'm not a web developer, but I have a WW 2.19 instance with Shibboleth setup and am happy to provide any information I can that might be of assistance in getting this to work. After applying 2609, in the admin instructors, all the navigation pages are now working, although various actions are still failing (note, have not even tried any of the user course things). Things still broke:
(1) In Accounts Manager, clicking save edit fails, with warning of:
Use of uninitialized value in hash element at template ContentGenerator/Login.html.ep line 12.
Use of uninitialized value in hash element at template ContentGenerator/Login.html.ep line 12.
(2) In Upgrade Courses, clicking Upgrade Courses fails, same error as above
(1) In Accounts Manager, clicking save edit fails, with warning of:
Use of uninitialized value in hash element at template ContentGenerator/Login.html.ep line 12.
Use of uninitialized value in hash element at template ContentGenerator/Login.html.ep line 12.
(2) In Upgrade Courses, clicking Upgrade Courses fails, same error as above
Working closely with me would mean meeting with me (via Zoom or such) to fix the issues. In fact, I am going to be meeting with Gavin LaRose next week to work on this. So hopefully we will get this sorted out soon.
The warnings "Use of uninitialized value in hash element at template ContentGenerator/Login.html.ep line 12." are actually inconsequential. You could set $LTI{v1p1}{LMS_name} in localOverrides.conf (and maybe another related variable) to eliminate those warnings. More consequential though is the fact that that code is even called when you are saving on the accounts manager page. That is showing a critical issue with the Shibboleth authentication module.
The warnings "Use of uninitialized value in hash element at template ContentGenerator/Login.html.ep line 12." are actually inconsequential. You could set $LTI{v1p1}{LMS_name} in localOverrides.conf (and maybe another related variable) to eliminate those warnings. More consequential though is the fact that that code is even called when you are saving on the accounts manager page. That is showing a critical issue with the Shibboleth authentication module.
So I would be willing to have a zoom meeting to fix issues. By adding following to localoverrides, I was able to get the contentGenenerator error to go away, but the net result is that most things no politely say, the course XXX uses an external authentication system (Shibboleth). Please return to that system to access the course. That message is in the login file, so my assumption is that further modification is needed in that file for the section where externalauth is used to allow it to proceed and actually do the work.
$LTIVersion = 'v1p1';
$LTI{v1p1}{LMS_name} = 'Shibboleth';
We are currently on version 2.16 and would like to switch to the latest version, but are dependent on Shibboleth. We would therefore be very happy to see further support for Shibboleth.
Unfortunately, I have no real idea about the WeBWorK security mechanisms. And what effect changes have on security. But with the patch #2609 and the commenting out of line 75 to 90 in the Shibboleth.pm (for testing purposes only), WeBWorK runs without errors so far. Cosign does not use any apparently comparable code, which leads to this attempt.
Although your rational for commenting out those lines is not quite correct, those lines do need to be removed for WeBWorK 2.19. Note that the Cosign authentication module is even more out of date than the Shibboleth authentication module, and comparing to that module is not a valid justification. For WeBWorK 2.17 and before lines 87-90 will be needed, but not lines 75-77. My justification for this comes from a much deeper analysis that I can't divulge at this point (mostly due to security concerns, but also because my analysis is not quite complete at this point).
I have put in a pull request that fixes the Shibboleth issues. It is at https://github.com/openwebwork/webwork2/pull/2612. In order to fix it, I installed and configured a Shibboleth identity provider of my own. So the pull request is not the guess like the previous one, and I have tested it personally. I would appreciate it if those of you that use Shibboleth authentication could test it.