Project

General

Profile

Actions
Copy link

action #167266

closed

openQA log reports "Failed to login" with no details in logs size:S

Added by okurz 3 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
High
Assignee:
ybonatakis
Category:
Feature requests
Target version:
openQA Project (public) - Ready
Start date:
2024-09-24
Due date:
2024-10-10
% Done:

0%

Estimated time:
Tags:
reactive work

Description

Observation

OpenQA logreport for ariel.suse-dmz.opensuse.org tells us this from time to time:

[2024-09-24T11:49:23.471863Z] [error] OpenID: Failed to login: OpenID provider returned invalid data. Please retry again

Suggestions

  • Consider improving the log message with more details but not revealing potentially sensitive information
  • Consider to reduce the severity of the log message if we can ensure there is a retry or know it is temporary

Related issues 1 (1 open — 0 closed)

Copied from openQA Infrastructure (public) - action #167263: OpenQA logreport regularly reports Failed to login in email size:MBlockedokurz

Actions
Actions
Copy link
 #1

Updated by okurz 3 months ago

  • Copied from action #167263: OpenQA logreport regularly reports Failed to login in email size:M added
Actions
Copy link
 #2

Updated by ybonatakis 3 months ago

  • Status changed from Workable to In Progress
  • Assignee set to ybonatakis
Actions
Copy link
 #3

Updated by openqa_review 3 months ago

  • Due date set to 2024-10-10

Setting due date based on mean cycle time of SUSE QE Tools

Actions
Copy link
 #4

Updated by ybonatakis 3 months ago

I tried to reproduce it in a couple of ways. Changing the provider URI or passing random consumer_secret but our code looks solid and catch all of those issues.
I checked the upstream code and it seems that the not_openqa is considered invalid when the args in https://github.com/gugu/net-openid-consumer/blob/master/lib/Net/OpenID/IndirectMessage.pm object does not have the openqa.mode properly assigned. (All the requests should have it apparently.
Then I thought to manipulate the params of the auth_response. The one that worked of all was the one with missing mode value.

To reproduce: add $params{'openid.mode'} = '' and try to authenticate.

i will provide a small PR changing the sting in the logs

Actions
Copy link
 #5

Updated by ybonatakis 3 months ago

  • Status changed from In Progress to Feedback
Actions
Copy link
 #6

Updated by ybonatakis 3 months ago

PR updated as per the discussion from the unblocked meeting this morning and following the suggestion crafted https://github.com/os-autoinst/openQA/pull/5952#discussion_r1784102963

Actions
Copy link
 #7

Updated by ybonatakis 3 months ago

  • Status changed from Feedback to Resolved

merged

Actions
Copy link
 #8

Updated by okurz 3 months ago

Follow-up based on demo feedback: https://github.com/os-autoinst/openQA/pull/5975

Actions
Copy link

Also available in: Atom PDF