action #125459
closed[o3-logwarn] error naive_verify_failed_return: Direct contact invalidated ID provider response. size:M
0%
Description
Observation¶
From email:
[2023-03-06T12:37:33.186220Z] [error] naive_verify_failed_return: Direct contact invalidated ID provider response.
access_log:
192.168.47.102 - - [06/Mar/2023:12:37:32 +0000] "POST /response?return_page=…&oic.time=… HTTP/1.1" 302 - "https://id.opensuse.org/" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 F
irefox/109.0" 316
Acceptance criteria¶
- AC1: We know what the error means
- AC2: The problem is dealt with or the error is ignored
Suggestions¶
- It is likely an error from
Net::OpenID::Consumer.
Updated by jbaier_cz about 1 year ago
That looks like an error from Net::OpenID::Consumer
Updated by mkittler about 1 year ago
- Subject changed from [o3-logwarn] error naive_verify_failed_return: Direct contact invalidated ID provider response. to [o3-logwarn] error naive_verify_failed_return: Direct contact invalidated ID provider response. size:M
- Description updated (diff)
- Status changed from New to Workable
Updated by mkittler about 1 year ago
- Status changed from Workable to In Progress
It comes from Net::OpenID::Consumer, indeed:
=item C<naive_verify_failed_return>
(V) An attempt to confirm a positive assertion via direct contact (check_authentication) received an explicitly negative response (C<openid.is_valid = FALSE>).
Updated by mkittler about 1 year ago
- Status changed from In Progress to Feedback
We're explicitly logging this error from the provider's error callback. We're also showing it the user in form of a flash message.
I've tried to provoke this locally but couldn't reproduce it playing around with our OpenID provider (e.g. clicking on the "Reject" button or entering false credentials didn't trigger the problem). According to the specification the error means that the signature of the verification request is not valid. I suspect there was something wrong on the remote side. Especially since it is working again, there's likely nothing to be fixed on our side.
For now I've created https://github.com/os-autoinst/openQA/pull/5034 for better context of the error message.
I guess we should decide whether we want to be alerted about this problem in the future. This time the alert wasn't really actionable (besides a slight improvement of the error message). I don't think it'll be actionable next time as well. So it would likely be best to ignore it in our alerting. We could either just ignore naive_verify_failed_return specifically or (when the PR has been merged) all OpenID-related errors. To be on the safe side, I'd created https://github.com/os-autoinst/openqa-logwarn/pull/44 to ignore only the specific error for now.
Updated by mkittler about 1 year ago
- Status changed from Feedback to Resolved
Both PRs have been merged so I'm considering this resolved.
Updated by okurz about 1 year ago
For such cases I suggest to use the "warn" loglevel and not "error". Just excluding from logwarn makes the issue not visible "for us" but not for other users of openQA.