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

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

Compare view mode:
  • Unified
    • Unified
    • Side-by-side
HTML view mode:
  • Unescaped
    • Unescaped
    • Escaped

Title

  • +{"en"=>"Include a bit of additional details in the HTTP 500 error page message"}
  • +{"en"=>"Include a bit of additional details in the HTTP 500 error page message"}
Deletions
Additions
  • +{"en"=>"Include a bit of additional details in the HTTP 500 error page message"}
Deletions
Additions
  • +{"en"=>"Include a bit of additional details in the HTTP 500 error page message"}

Body

  • +["

    **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.

    "]
  • +["<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>"]
Deletions
  • 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.

"]
Additions
  • +["

    **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.

    "]
Deletions
Additions
  • +["<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>"]
Version number 1 out of 1 Show all versions Go back to proposal
Version author
Avatar: Antti Hukkanen Antti Hukkanen
Version created at 14/01/2021 16:23
  • 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?