[Bug]: ResourceModule raises 500 on stale or invalid ids in edit/delete flows
esp/esp/program/modules/handlers/resourcemodule.py performs several edit/delete admin flows by calling .objects.get(id=request.GET['id']) directly, without guarding against missing, stale, or invalid ids.
This affects multiple handler paths in the same module:
resources_timeslot()resources_restype()resources_classroom()resources_equipment()
Relevant code paths include direct lookups such as:
Event.objects.get(id=request.GET['id'])ResourceType.objects.get(id=request.GET['id'])Resource.objects.get(id=request.GET['id'])
Why this matters
These are admin-facing edit/delete workflows. If an id is stale, tampered with, or simply points to a deleted object, the handler raises DoesNotExist and returns a 500 instead of failing gracefully.
That makes the resource-management UI fragile in normal real-world situations such as:
- bookmarked old admin links
- two admins working concurrently
- deleting an item and later revisiting its edit/delete URL
- manually modified query parameters
Steps to Reproduce
- Open
esp/esp/program/modules/handlers/resourcemodule.py.
- Locate these branches:
resources_timeslot() with op=edit / op=deleteresources_restype() with op=edit / op=deleteresources_classroom() with op=edit / op=deleteresources_equipment() with op=edit / op=delete
- Note that each branch dereferences
request.GET['id'] via .objects.get(...) without any try/except, .filter().first(), or validation guard.
- Request one of those views with a missing/deleted/nonexistent id.
Expected Behavior
The handler should fail gracefully, for example by:
- showing an error message
- redirecting back to the resource-management page
- returning a 404 or other controlled response
Actual Behavior
The handler can raise Event.DoesNotExist, ResourceType.DoesNotExist, or Resource.DoesNotExist, which surfaces as a 500.
Impact
A stale link in the admin UI can crash core resource-management pages for timeslots, resource types, classrooms, and equipment. Because the same pattern appears in several flows in one module, this is broader than a single broken endpoint.
Suggested Fix
Guard these lookups before using them, for example by:
- validating that
id is present and integer-like
- using
filter(...).first() where appropriate
- catching
DoesNotExist and returning a controlled error/redirect
- centralizing the lookup/error handling so the four affected flows behave consistently
Additional Context
I checked the current tracker for existing issues covering ResourceModule stale/invalid id crashes across these edit/delete flows and did not find an existing open issue matching this behavior.
[Bug]: ResourceModule raises 500 on stale or invalid ids in edit/delete flows
esp/esp/program/modules/handlers/resourcemodule.pyperforms several edit/delete admin flows by calling.objects.get(id=request.GET['id'])directly, without guarding against missing, stale, or invalid ids.This affects multiple handler paths in the same module:
resources_timeslot()resources_restype()resources_classroom()resources_equipment()Relevant code paths include direct lookups such as:
Event.objects.get(id=request.GET['id'])ResourceType.objects.get(id=request.GET['id'])Resource.objects.get(id=request.GET['id'])Why this matters
These are admin-facing edit/delete workflows. If an id is stale, tampered with, or simply points to a deleted object, the handler raises
DoesNotExistand returns a 500 instead of failing gracefully.That makes the resource-management UI fragile in normal real-world situations such as:
Steps to Reproduce
esp/esp/program/modules/handlers/resourcemodule.py.resources_timeslot()withop=edit/op=deleteresources_restype()withop=edit/op=deleteresources_classroom()withop=edit/op=deleteresources_equipment()withop=edit/op=deleterequest.GET['id']via.objects.get(...)without anytry/except,.filter().first(), or validation guard.Expected Behavior
The handler should fail gracefully, for example by:
Actual Behavior
The handler can raise
Event.DoesNotExist,ResourceType.DoesNotExist, orResource.DoesNotExist, which surfaces as a 500.Impact
A stale link in the admin UI can crash core resource-management pages for timeslots, resource types, classrooms, and equipment. Because the same pattern appears in several flows in one module, this is broader than a single broken endpoint.
Suggested Fix
Guard these lookups before using them, for example by:
idis present and integer-likefilter(...).first()where appropriateDoesNotExistand returning a controlled error/redirectAdditional Context
I checked the current tracker for existing issues covering
ResourceModulestale/invalid id crashes across these edit/delete flows and did not find an existing open issue matching this behavior.