SecurityTransgression raised by Doorkeeper
mmulich opened this issue · comments
I attempted to access doorkeeper (//{host}/oauth/applications/new) with a non-admin user, instead of a health 403 or something similar, I got a traceback. At first I didn't realize I was using a non-admin user, so I was trying to track down the source of the error, because I thought the application did something wrong.
I guess I would have expected a 403 forbidden page rather than an error. Thoughts?
There should not be a traceback since it will give someone trying for
unauthorized access information they might be able to use.
On 03/11/2015 08:16 AM, Michael Mulich wrote:
I attempted to access doorkeeper (//{host}/oauth/applications/new)
with a non-admin user, instead of a health 403 or something similar, I
got a traceback. At first I didn't realize I was using a non-admin
user, so I was trying to track down the source of the error, because I
thought the application did something wrong.I guess I would have expected a 403 forbidden page rather than an
error. Thoughts?—
Reply to this email directly or view it on GitHub
#148.!DSPAM:1106,5500404151411993113623!
We need to put the error page infrastructure in for our nonstandard errors. I think there's an issue. We have code in other apps we can use.
On Mar 11, 2015, at 6:16 AM, Michael Mulich notifications@github.com wrote:
I attempted to access doorkeeper (//{host}/oauth/applications/new) with a non-admin user, instead of a health 403 or something similar, I got a traceback. At first I didn't realize I was using a non-admin user, so I was trying to track down the source of the error, because I thought the application did something wrong.
I guess I would have expected a 403 forbidden page rather than an error. Thoughts?
—
Reply to this email directly or view it on GitHub.
The traceback is shown only in development configurations. On production environments, you see a blank page. The blank page should be replaced by something more helpful once we implement JP's suggestion above.
Was this on a local dev instance or one of the deployed instances?
On Mar 11, 2015, at 6:41 AM, Ed Woodward notifications@github.com wrote:
There should not be a traceback since it will give someone trying for
unauthorized access information they might be able to use.On 03/11/2015 08:16 AM, Michael Mulich wrote:
I attempted to access doorkeeper (//{host}/oauth/applications/new)
with a non-admin user, instead of a health 403 or something similar, I
got a traceback. At first I didn't realize I was using a non-admin
user, so I was trying to track down the source of the error, because I
thought the application did something wrong.I guess I would have expected a 403 forbidden page rather than an
error. Thoughts?—
Reply to this email directly or view it on GitHub
#148.!DSPAM:1106,5500404151411993113623!
—
Reply to this email directly or view it on GitHub.
that it is a blank page in production is somewhat unexpected as standard rails error pages should be kicking in.
On Mar 11, 2015, at 6:54 AM, Lakshmi notifications@github.com wrote:
The traceback is only in development configurations. On production environments, you see a blank page. The blank page should be replaced by something more helpful once we implement JP's suggestion above.
—
Reply to this email directly or view it on GitHub.
Something is not configured properly probably, because #126
Is this fixed now that we have error pages?
Should be fixed. You will still get a backtrace in dev (local) but we won't change that.
Please close if this is solved or let us know otherwise.