This site uses cookies. By continuing to browse the site, you agree to our use of cookies. Find out more about cookies.
Skip to main content
Metadecidim's official logo
  • English Triar la llengua Elegir el idioma Choose language
    • Català
    • Castellano
Sign Up Sign In
  • Home
  • Processes
  • Assemblies
  • Initiatives
  • Consultations
  • Conferences
  • Help

Propose new functionalities for Decidim software

#DecidimRoadmap Designing Decidim together

Phase 1 of 1
Open 2019-01-01 - 2030-12-31
Process phases Submit a proposal
  • The process
  • Debates
  • Propose new features
  • News
chevron-left Back to list

Include a bit of additional details in the HTTP 500 error page message

Avatar: Antti Hukkanen Antti Hukkanen
14/01/2021 16:23  

**Is your feature request related to a problem? Please describe.**

When users will see the HTTP 500 page that states "There was a problem with our server", they generally just report this issue by copying the text on that page or by posting a screenshot.

Many times we can identify the correct error log entry by looking at the time of the report but sometimes it can be quite different than when the error actually happened.

This makes it sometimes hard to find the root cause of that particular user's problem.

**Describe the solution you'd like**

I'd like to add a bit of additional details to the HTTP 500 page. Not something that could potentially reveal sensitive information but at least something in order to map the correct log entry to the problem a bit easier.

I suggest adding the exact date+time stamp that appears in the logs to that page. On top of that, we could add a note stating: "Report this issue to the maintainers of this platform with the following details". Below that, we could add a box that includes some information to better identify the root cause.

This information could be:

  • Date+time of the exception as it appears in the log entry
  • User ID/nickname
  • The URL at the time of error
  • HTTP request method (GET/POST/etc.)

**Describe alternatives you've considered**

Looking at the time of the error report usually gives a slight hint when the error happened. But this information can be also lost in the email chains once it reaches the developers.

**Additional context**

Similar non-identifying information is typically included also in automated bug reports in the different operating systems. Some other software also implement such feature.

**Does this issue could impact on users private data?**

As the error report includes the user's ID or nickname, it reveals a bit of private data. However, typically they use the same email to report the issue anyways based on which you can also identify which user it was on the platform.

It should be also considered carefully what details to include with the additional report data. In case too much information is added, it has a potential impact on the private data. E.g. POST data should not be generally included since it could include some sensitive information e.g. during the OmniAuth callbacks.

**Funded by**

No funding available yet.

  • Filter results for category: Administration Administration

List of Endorsements

Avatar: Virgile Deville Virgile Deville
Avatar: álvaro ortiz álvaro ortiz verified-badge
Endorsements count2
Include a bit of additional details in the HTTP 500 error page message Comments 1

Reference: MDC-PROP-2021-01-15923
Version number 1 (of 1) see other versions
Check fingerprint

Fingerprint

The piece of text below is a shortened, hashed representation of this content. It's useful to ensure the content hasn't been tampered with, as a single modification would result in a totally different value.

Value: 03b34acb6741a09f0e8f9f812b9baff4c8a6ac21e10f6145cfbf338f8c0362fe

Source: {"body":{"en":"<p><strong>**Is your feature request related to a problem? Please describe.**</strong></p><p>When users will see the HTTP 500 page that states \"There was a problem with our server\", they generally just report this issue by copying the text on that page or by posting a screenshot.</p><p>Many times we can identify the correct error log entry by looking at the time of the report but sometimes it can be quite different than when the error actually happened.</p><p>This makes it sometimes hard to find the root cause of that particular user's problem.</p><p><strong>**Describe the solution you'd like**</strong></p><p>I'd like to add a bit of additional details to the HTTP 500 page. Not something that could potentially reveal sensitive information but at least something in order to map the correct log entry to the problem a bit easier.</p><p>I suggest adding the exact date+time stamp that appears in the logs to that page. On top of that, we could add a note stating: \"Report this issue to the maintainers of this platform with the following details\". Below that, we could add a box that includes some information to better identify the root cause.</p><p>This information could be:</p><ul><li>Date+time of the exception as it appears in the log entry</li><li>User ID/nickname</li><li>The URL at the time of error</li><li>HTTP request method (GET/POST/etc.)</li></ul><p><strong>**Describe alternatives you've considered**</strong></p><p>Looking at the time of the error report usually gives a slight hint when the error happened. But this information can be also lost in the email chains once it reaches the developers.</p><p><strong>**Additional context**</strong></p><p>Similar non-identifying information is typically included also in automated bug reports in the different operating systems. Some other software also implement such feature.</p><p><strong>**Does this issue could impact on users private data?**</strong></p><p>As the error report includes the user's ID or nickname, it reveals a bit of private data. However, typically they use the same email to report the issue anyways based on which you can also identify which user it was on the platform.</p><p>It should be also considered carefully what details to include with the additional report data. In case too much information is added, it has a potential impact on the private data. E.g. POST data should not be generally included since it could include some sensitive information e.g. during the OmniAuth callbacks.</p><p><strong>**Funded by**</strong></p><p>No funding available yet.</p>"},"title":{"en":"Include a bit of additional details in the HTTP 500 error page message"}}

This fingerprint is calculated using a SHA256 hashing algorithm. In order to replicate it yourself, you can use an MD5 calculator online and copy-paste the source data.

Share:

link-intact Share link

Share link:

Please paste this code in your page:

<script src="https://meta.decidim.org/processes/roadmap/f/122/proposals/15923/embed.js"></script>
<noscript><iframe src="https://meta.decidim.org/processes/roadmap/f/122/proposals/15923/embed.html" frameborder="0" scrolling="vertical"></iframe></noscript>

Report inappropriate content

Is this content inappropriate?

Reason

1 comment

Order by:
  • Older
    • Best rated
    • Recent
    • Older
    • Most discussed
Avatar: Andrés Andrés verified-badge
11/02/2021 10:23
  • Get link Get link

This would be awesome!!

Right now the troubleshooting involves going to an exception tracking system, like Errbit/Sentry/Rollbar and filtering by this controller/URL/user. Other times is easier to just say: "Can you do that again?" and do some tail -f or similar.

Other platforms what they do is give some kind of ID of the exception so the user can copy and send it, and then the administrators can look for this ID and the extra information.

Add your comment

Sign in with your account or sign up to add your comment.

Loading comments ...

  • Terms and conditions of use
  • About the community
  • Download Open Data files
  • Metadecidim at Twitter Twitter
  • Metadecidim at Instagram Instagram
  • Metadecidim at YouTube YouTube
  • Metadecidim at GitHub GitHub
Creative Commons License Website made with free software.
Decidim Logo

Confirm

OK Cancel

Please sign in

decidim Sign in with Decidim
Or

Sign up

Forgot your password?