You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was logging in my existing Gmail account automatically with existing cookie that was correctly not authorized for access due to domain.
However, The login appeared to succeed and the resource listing page displayed (with no data). Indicating login authorized , It would be good to redirect to loggedout or a 401.
The confidant_session token was also set despite logs showing failed authorization. It of course appears to be correctly unauthorized.
When I click create service I got this error. Which had me thinking my AWS infra was misnamed or my dynamodb tables had not been nuked before recreation during provisioning. It is due to the correct 403 on all v1/ resources.
{{ grantUpdateError }}
{{ saveError }}
The following credential pair keys conflict in the listed credentials:
Please ensure credential pair keys are unique, then try again.
Service ID {{ service.id || "Not set." }} {{ service.id || "Not set." }}
AWS Account {{ service.account }} No account scoping No account scoping
Service Enabled {{ service.enabled }}
The text was updated successfully, but these errors were encountered:
russmac
changed the title
Improved response to unauthorized user.
Improved response to unauthorized user / Session token set with unauthorized user.
Sep 7, 2016
Ideally this would redirect to another page that gave a proper error message, rather than logged out, so that people get an indication that they've made a mistake.
I was logging in my existing Gmail account automatically with existing cookie that was correctly not authorized for access due to domain.
However, The login appeared to succeed and the resource listing page displayed (with no data). Indicating login authorized , It would be good to redirect to loggedout or a 401.
The confidant_session token was also set despite logs showing failed authorization. It of course appears to be correctly unauthorized.
When I click create service I got this error. Which had me thinking my AWS infra was misnamed or my dynamodb tables had not been nuked before recreation during provisioning. It is due to the correct 403 on all v1/ resources.
The text was updated successfully, but these errors were encountered: