Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore custom error views (but return JSON where desired) #11722 #11784

Merged
merged 2 commits into from
Feb 14, 2025

Conversation

jacobtylerwalls
Copy link
Member

@jacobtylerwalls jacobtylerwalls commented Feb 11, 2025

Types of changes

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description of Change

This PR addresses two issues:

  • Arches used to have generic error views, but they were removed from the core URL config in f8a5045. This PR restores them to the config and models in the release notes how to make sure your project uses them.
  • Not every view that is supposed to return JSON returns JSON in every single error circumstance. One scenario with a view decorator is described in Add error handlers for api routes #11722, but there is no bulletproof way to catch every error without leveraging Django's built-in error views. If we do this, then front-end parsers that expect to call .json() on a response body won't throw when they get an HTML response from the generic (or customized) error view.

Issues Solved

Closes #11722

Checklist

  • I targeted one of these branches:
    • dev/8.0.x (under development): features, bugfixes not covered below
    • dev/7.6.x (main support): regressions, crashing bugs, security issues, major bugs in new features
    • dev/6.2.x (extended support): major security issues, data loss issues
  • I added a changelog in arches/releases
  • I submitted a PR to arches-docs (if appropriate)
  • Unit tests pass locally with my changes
  • I added tests that prove my fix is effective or that my feature works
  • My test fails on the target branch

Ticket Background

  • Sponsored by: Getty Conservation Institute

def looks_like_api_call(request):
known_api_paths_without_api_signposting = [
# Until these are renamed for consistency, just list them.
"arches.app.views.workflow_history",
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can add more as we find them, but I'm considering it out of scope to audit everything right now: that's a lot of views to analyze. See next comment for why this one is here.

Comment on lines -86 to +89
self.assertEqual(response.status_code, 403)
self.assertIn(b"Forbidden", response.content)
self.assertContains(
response, "Permission Denied", status_code=HTTPStatus.FORBIDDEN
)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because this error condition was already tested, we caught an example of HTML where we should have sent JSON.

Before:

\n<!doctype html>\n<html lang="en">\n<head>\n  <title>403 Forbidden</title>\n</head>\n<body>\n  <h1>403 Forbidden</h1><p></p>\n</body>\n</html>\n

After:

{"message": "Permission Denied", "status": "false", "success": false, "title": "Request Failed"}

@@ -781,9 +781,13 @@
api.SpatialView.as_view(),
name="spatialview_api",
),
re_path("^api", api.API404.as_view(), name="api_404"),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now we don't need this anymore to handle errors, which is good, because it was too fragile in practice (sneaky failures depending on the order in which you included your other URLs)

Copy link
Collaborator

@njkim njkim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@njkim njkim merged commit 31ff7cb into dev/8.0.x Feb 14, 2025
7 checks passed
@jacobtylerwalls jacobtylerwalls deleted the jtw/custom-error-handlers branch February 14, 2025 19:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add error handlers for api routes
2 participants