-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Add network specific error message to avoid confusion #2367
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thank you for your contribution! This looks pretty good and I have some ideas how to improve it further :)
@@ -316,6 +318,11 @@ func (m *RegistryBase) ScopeStrategy() fosite.ScopeStrategy { | |||
|
|||
func (m *RegistryBase) newKeyStrategy(key string) (s jwk.JWTStrategy) { | |||
if err := jwk.EnsureAsymmetricKeypairExists(context.Background(), m.r, new(jwk.RS256Generator), key); err != nil { | |||
var netError net.Error | |||
if errors.As(err, &netError) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be **netError
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case I don't believe so, as net.Error
is an interface. It worked when I tested it locally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, that makes sense! Maybe we could add a small test to ensure we don't regress on this in future iterations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'll see what I can do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aeneasr i'm having trouble writing tests for this due to the fact that we call .Fatalf
as part of the error logging, which inevitably leads to os.Exit(1)
. Do have any advice/examples on how I might write tests for this? Thanks.
Edit: I can replace ExitFunc
on the Logrus instance to prevent the call to os.Exit
, however, execution will continue after the log call is made. I don't think it makes sense to explicitly call return
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's ok, you can call return explicitly here!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thank you! 🎉 Your contribution makes Ory better :)
Related issue
#2338
Proposed changes
In the event of a general network error, avoid logging a misleading/confusing message.
Checklist
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.
works.
Further comments