Handlers don't work from remote services

[nedbat]

From a developer:

[quote]
All the handlers I am creating that are accessed by remote tools using POST requests (settings service, outcomes service and memberships service) are all blocked by django's CSRF protection. Adding the @csrf_exempt decorator to the handlers in the XBlock has no effect. I have only been able to get it working by adding @csrf_exempt to the handler function in workbench/views.py

diff --git a/workbench/views.py b/workbench/views.py
index b8f97e6..72037a5 100644
--- a/workbench/views.py
+++ b/workbench/views.py@@ -75,7 +76,9 @@ def show_scenario(request, scenario_id, view_name='student_view'):
})

+from django.views.decorators.csrf import csrf_exempt
+@csrf_exempt
def handler(request, usage_id, handler_slug):
student_id = get_student_id(request)
log.info("Start handler %s/%s for student %s", usage_id, handler_slug, student_id)
usage = Usage.find_usage(usage_id)

[end quote]

Clearly, we don't want to exempt all handlers from CSRF protection, so we need a way to indicate which handlers are from the authenticated browser, and which are not.

[cpennington]

We had talked in the past about giving the runtime the ability to give the
XBlock one-time (or small-window) urls for remote access to specific
handlers, for use with external services (I guess we could also do it as
shared key basic auth, as long as we knew we were running inside https).

From other conversations, we've had a request to have XBlocks be able to
have OAuth authenticated handlers. Perhaps we just need a way to configure
particular handlers to support different authentication schemes (where the
default is runtime-authenticated).

[Pugio]

Has there been any change in this? I know it's been a while, but I can't seem to avoid CSRF protection when trying to post to an LTI XBlock's outcome_service_handler. LTI is already authenticated (via OAuth), and right now it seems as though I can't post any grades back to the site (via lis_outcome_service_url), because the CSRF protection gets in the way.

[geoff-va]

@Pugio I don't know if/when this was changed (or maybe it's always been this way), but there is a thirdparty=True flag set on those services in the runtime.handler_url calls - link here.

I'm doing a little dev work and was able to POST back to a handler endpoint as long as I fetched the url using self.runtime.handler_url('name', thirdparty=True). This flag makes the endpoint csrf_exempt here. (This is ironwood, FYI)

Can you confirm that the lti-consumer xblock you're using has that thirdparty flag set, and what edx version you're using?

[AxelSilverdew]

@Pugio I don't know if/when this was changed (or maybe it's always been this way), but there is a thirdparty=True flag set on those services in the runtime.handler_url calls - link here.

I'm doing a little dev work and was able to POST back to a handler endpoint as long as I fetched the url using self.runtime.handler_url('name', thirdparty=True). This flag makes the endpoint csrf_exempt here. (This is ironwood, FYI)

Can you confirm that the lti-consumer xblock you're using has that thirdparty flag set, and what edx version you're using?

I can't seem to get this working in the xblock workbench. 🤔

I'm getting the url with the function you mentioned and it gives me /unauth_handler/block.block.d0.u0/test but if I try to POST to http://localhost:8000/unauth_handler/block.block.d0.u0/test I still get hit with a csrf wall. :/

Is there a better way to do this these days?