Skip to content

Comments

feat: error_hint and error_debug are now exposed through error_description#460

Merged
aeneasr merged 14 commits intoory:masterfrom
mitar:error-hints
Sep 16, 2020
Merged

feat: error_hint and error_debug are now exposed through error_description#460
aeneasr merged 14 commits intoory:masterfrom
mitar:error-hints

Conversation

@mitar
Copy link
Contributor

@mitar mitar commented Aug 13, 2020

Related issue

Fixes #456.

Proposed changes

When error_description is send out, it includes now error_hint (if present) and error_debug (if present and enabled to be send). Because error_description is standard this allows easier access to that information.

error_hint and error_debug fields are left as-is for backwards compatibility purposes. error_verbose is added to provide only the old error description.

Checklist

  • I have read the contributing guidelines
  • I have read the security policy
  • I confirm that this pull request does not address a security
    vulnerability. If this pull request addresses a security vulnerability, I
    confirm that I got green light (please contact
    security@ory.sh) from the maintainers to push
    the changes.
  • I have added tests that prove my fix is effective or that my feature works
  • I have added necessary documentation within the code base (if appropriate)

@mitar mitar closed this Aug 22, 2020
@mitar mitar reopened this Aug 22, 2020
@mitar
Copy link
Contributor Author

mitar commented Aug 22, 2020

Closing and reopening to trigger tests to run.

Copy link
Member

@aeneasr aeneasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! I think this will appear in a couple of other places as well (introspection?). I also had the idea that we could improve all of this a bit more by making RFCError a JSONUnmarshaller and add a method AsQueryString() string which would do the modifications instead of handling this. The only problem would be that f.SendDebugMessagesToClients would need to be passed to these functions somehow.

@aeneasr
Copy link
Member

aeneasr commented Aug 29, 2020

Once again, sorry for the late review! By the way, if you allow edits from maintainers I should be able to synch the branches and make the nancy failure go away :)

@aeneasr aeneasr added breaking change Changes behavior in a breaking manner. feat New feature or request. labels Aug 29, 2020
@aeneasr aeneasr self-assigned this Aug 29, 2020
@mitar
Copy link
Contributor Author

mitar commented Aug 29, 2020

By the way, if you allow edits from maintainers I should be able to synch the branches and make the nancy failure go away

It should already be on.

@aeneasr
Copy link
Member

aeneasr commented Aug 29, 2020

Yes, my bad, I had to change something in the repository settings!

@mitar
Copy link
Contributor Author

mitar commented Aug 29, 2020

About JSONUnmarshaller, yea, I have no idea how to pass this, unless we do something like:

if !config.SendDebugMessagesToClients {
   error = error.WithDebug("")
}

And then leave to JSONUnmarshaller to serialize.

@mitar
Copy link
Contributor Author

mitar commented Aug 29, 2020

Or maybe we make Sanitize method on the error, which does the above, accepting boolean if it should sanitize or not. And then you call error.Sanitize(!config.SendDebugMessagesToClients) or something.

@aeneasr
Copy link
Member

aeneasr commented Aug 29, 2020

Hm yeah in that case it probably makes sense to just keep it as is!

@aeneasr
Copy link
Member

aeneasr commented Aug 31, 2020

Just to double-check, this would now be good for merge right?

@mitar mitar changed the title feat: error_hint and error_debug are now exposed through error_description WiP: feat: error_hint and error_debug are now exposed through error_description Aug 31, 2020
@mitar
Copy link
Contributor Author

mitar commented Aug 31, 2020

No, I have not yet updated it based on your comments. My plan is:

  • Make descriptions multi line (I am personally not too sure about it, but if you like it, sure).
  • Make ErrorToRFC6749Error return by value, not ref.
  • Implement JSONUnmarshaller and AsQueryString.
  • Add Sanitize.

@mitar mitar marked this pull request as draft August 31, 2020 21:21
@mitar mitar changed the title WiP: feat: error_hint and error_debug are now exposed through error_description feat: error_hint and error_debug are now exposed through error_description Aug 31, 2020
@aeneasr
Copy link
Member

aeneasr commented Aug 31, 2020

Ok sounds good :)

@mitar mitar marked this pull request as ready for review September 5, 2020 05:19

func (f *Fosite) IntrospectToken(ctx context.Context, token string, tokenType TokenType, session Session, scopes ...string) (TokenType, AccessRequester, error) {
var found bool = false
var found = false
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not necessary.

} else if err.Error() == ErrUnknownRequest.Error() || errors.Cause(err).Error() == ErrUnknownRequest.Error() {
// Nothing to do
} else if err != nil {
} else {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This condition was unnecessary and always true.

for _, validator := range f.TokenIntrospectionHandlers {
tt, err := validator.IntrospectToken(ctx, token, tokenType, ar, scopes)
if err := errors.Cause(err); err == nil {
if err == nil {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I simplified the logic here a bit. ErrorToRFC6749Error uses Cause internally as well, so I think this now is clearer and easier to read.

@mitar
Copy link
Contributor Author

mitar commented Sep 5, 2020

@aeneasr I finished things from my side. Please review again. When merging, please squash commits. (Or do you want me to squash them?)

@mitar mitar requested a review from aeneasr September 5, 2020 05:33
@aeneasr
Copy link
Member

aeneasr commented Sep 7, 2020

All good, I'll squash them :)

@mitar
Copy link
Contributor Author

mitar commented Sep 8, 2020

Please see my comments above and tell me your final decisions so that I know what to do.

Copy link
Member

@aeneasr aeneasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, almost there :) Still on vacation until September 23rd so response times might be a bit longer!

@mitar
Copy link
Contributor Author

mitar commented Sep 15, 2020

I updated the PR.

Enjoy vacations, no hurry with this one.

Copy link
Member

@aeneasr aeneasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! :)

@aeneasr aeneasr merged commit 8daab21 into ory:master Sep 16, 2020
@mitar mitar deleted the error-hints branch September 16, 2020 18:00
@mitar mitar mentioned this pull request Sep 20, 2020
5 tasks
@nerocrux
Copy link
Contributor

@mitar @aeneasr
Thank you for your work!
It's not important but I wonder if it is possible to provide an option for removing error_verbose from the error response because the message in error_verbose and error_description feels duplicated for me.

@mitar
Copy link
Contributor Author

mitar commented Sep 24, 2020

I would suggest we simply make UnmarshalJSON always return an error and remove error_verbose altogether. So error_verbose is there just to support UnmarshalJSON, but UnmarshalJSON is not really needed/used at all in this codebase. I implemented it just for completeness.

@mitar
Copy link
Contributor Author

mitar commented Sep 24, 2020

Also, how people feel about removing error_hint and error_debug? Or should we just maybe mark them in a comment as 'deprecated pending future removal" and then remove them in half a year or so?

@nerocrux
Copy link
Contributor

@mitar
Thank you for your reply.

I would suggest we simply make UnmarshalJSON always return an error and remove error_verbose altogether.

I agree with you.

how people feel about removing error_hint and error_debug?

I'm a user of fosite (not hydra) so my opinion's maybe not complete but I'm totally OK with removing error_hint and error_debug (merging them into error_description).

@lazeratops
Copy link

Came here to ask about the same thing - error_verbose seems redundant. If error_hint and error_debug are already merged into error_description I am fine removing them (as a caveat also just a fosite user, not hydra, not sure exactly how it would affect hydra users). To clarify for sanity purposes, to ensure I am seeing intended behaviour: the only one of these fields that is not intended to be exposed back to the client by default is error_debug, correct?

@aeneasr
Copy link
Member

aeneasr commented Sep 24, 2020

Those fields will be eventually deprecated. In the meanwhile, simply ignore them!

@lazeratops
Copy link

We can definitely ask the client to ignore them; the main reason I was asking is to confirm that our auth service is not leaking any info that it shouldn't and is up to spec with the RFC. When we run WriteAuthorizeError() via the fosite provider, the response fosite produces to send back to the client does include those error_verbose fields and error hints in its current state. I wanted to confirm that we are not meant to be sanitizing any of this away (except for the debug info, which is already sanitized by fosite)

@mitar
Copy link
Contributor Author

mitar commented Sep 24, 2020

Yes, those are fine. There is no extra information provided with these new fields, just merging them into error_description.

@nerocrux
Copy link
Contributor

Thanks. I'm OK with this. But please allow me to confirm:

  1. There is no way to remove error_verbose from error response (e.g. token endpoint) and the decision is we don't remove it for now.
  2. Do you have any plan on the deprecation of these fields?

Thank you.

@aeneasr
Copy link
Member

aeneasr commented Sep 28, 2020

Yes, these will be deprecated in the upcoming release!

@aeneasr
Copy link
Member

aeneasr commented Nov 12, 2020

For anyone following this thread - I had to introduce some changes to this original PR. You can find the changeset here: e463674

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breaking change Changes behavior in a breaking manner. feat New feature or request.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make error_hint be part of error_description

4 participants