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

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

Compare view mode:

HTML view mode:

Title

+{"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.
"]

+["**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:<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>**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

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

+["**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:<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>**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."]

Version number 1 out of 1 Show all versions Go back to proposal

Version author

Antti Hukkanen

Version created at 14/01/2021 16:23