Add permissions to render problems with WebworkWebservice.

[somiaj]

First, this adds the permission webservice_render_problem used to determine if a user can render a problem with the WebworkWebservice, instead of using the proctor_quiz_login permission for this.

Second, this adds an additional permission webservice_render_source used to determine if a user can render problems using the problem provided with the request. The use case for this is to allow users which can render problems only using a problem filename, but not by providing the problem's source.

These permissions are both set to login_proctor to match current behavior and are provided to allow server admins to change which users can render problems. These permissions are not added to the course configuration page as they are permissions that should not be modified by most users, only server admins via localOverrides.conf or course.conf.

One way to test this is to set webservice_render_source to nobody, and see that pages like the library browser still work since rendering is done via filenames, but the problem editor no longer works.

[somiaj]

Permission checked moved and updated using @drgrice1 suggested code.

[drgrice1]

I am wondering if this is the right way to go at all. I think that rather than using permissions at all which is really tit-for-tat on the current setup, there should be a "white list" of users that are allowed to render problem source, but the "white list" only applies for the case that unsecured rpc usage is allowed and cookies are disabled for the request. The point is that this is even more specific than a permission, and that I think this is something that only should apply at all in the case that unsecured rpc usage is being utilized.

[somiaj]

That could work, though I am unsure how to apply it to my use case. It appears that allow_unsecured_rpc is a server setting and not a course setting. In my setup, I have a single course with two users, my admin user and the login_proctor public user, which I have disabled two factor auth for. I don't see the need to setup a second webwork server for this, when at the moment I can just setup a single course for that.

[drgrice1]

I think that separating the renderProblem permission from the proctor_quiz_login permission is good, and further separating the capability of rendering problem source into another permission is also good.

I think that even better security for the allow_unsecured_rpc setting would also be good to implement in the future. Although perhaps that is a bit silly since that is always going to be unsecured. At least in the PreTeXt case, there is a user whose credentials are entirely public that is allowed to run untrusted code. There probably is nothing that can really be done to protect that.

[Alex-Jordan]

Local pg rendering could become the norm for static PTX production. And we could develop a way to use a renderer local to the web server for pretext live rendering. And then after a year or two of deprecation notices, we could close the insecure access to a webwork2 server. Alex Jordan Mathematics Instructor Portland Community College

…

On Sat, Nov 8, 2025, 10:45 AM Glenn Rice ***@***.***> wrote: ***@***.**** approved this pull request. I think that separating the renderProblem permission from the proctor_quiz_login permission is good, and further separating the capability of rendering problem source into another permission is also good. I think that even better security for the allow_unsecured_rpc setting would also be good to implement in the future. Although perhaps that is a bit silly since that is always going to be unsecured. At least in the PreTeXt case, there is a user whose credentials are entirely public that is allowed to run untrusted code. There probably is nothing that can really be done to protect that. — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/openwebwork/webwork2/pull/2844*pullrequestreview-3438517117__;Iw!!Ka_JY85zDv0FFw!kwXNEaq0wvZ9yc9wW8fhPG2N-iqFnvnMuhhMdW9GQHqb83GdTcsKesRiqfHGJaf1XYz95RzOJyWLBh-Go7c_cfK2sA0$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABEDOAEIBA75SRQQX3HX3XD33YZBFAVCNFSM6AAAAACLRA7TECVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTIMZYGUYTOMJRG4__;!!Ka_JY85zDv0FFw!kwXNEaq0wvZ9yc9wW8fhPG2N-iqFnvnMuhhMdW9GQHqb83GdTcsKesRiqfHGJaf1XYz95RzOJyWLBh-Go7c_o9HbIkM$> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>