openstax / accounts

OpenStax centralized authentication and accounts service

Home Page:https://accounts.openstax.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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.