openedx / XBlock

Framework for building custom learning components that run in the Open edX LMS!
https://docs.openedx.org/projects/xblock/en/latest/xblock-tutorial/index.html
Apache License 2.0
452 stars 217 forks source link

Handlers don't work from remote services #13

Open nedbat opened 11 years ago

nedbat commented 11 years ago

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 commented 11 years ago

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 commented 5 years ago

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 commented 5 years ago

@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?