Could @hricky do the following:
- go to https://id.fedoraproject.org/logout and try again
- make sure he is using hricky as username, not his email address

If that does not help, could he try logging in to https://stg.pagure.io/ ? Does it work there?

Thanks.

He reports that: 'Logging out and logging in again didn't help. Logging to https://stg.pagure.io/ returns "OpenID request was cancelled".'
And yes, he says that he is using the username and not the email address.

Thanks.

Weird, I don't see the attempts in the logs. Could he ping me on IRC/Matrix? I'm abompard on #fedora-infra or #fedora-apps

is @hricky able to log in with his credentials to https://accounts.fedoraproject.org/ ?

OK, the login seems successful in Ipsilon, I see the redirect from Ipsilon to Pagure, and I see nothing wrong in the Pagure logs, but the user is still not logged in.
Could someone with Pagure knowledge help out here? I don't know what's going on...

@pingou could you look possibly?

is @hricky able to log in with his credentials to https://accounts.fedoraproject.org/ ?

Sorry for the late reply. Yes, he is able to login to accounts and to Ask Fedora as well.

@hricky and I looked into it a little bit earlier today but ran short of ideas. There are no errors on the pagure side and what shows on the web-console isn't inspiring either:

{"errcode":"M_NOT_FOUND","error":"Not found","mr_errcode":"M_NOT_FOUND"}

@hricky was able to reproduce it in private browsing, in different browser and even different OSes. So the issue seems to be related to the account itself.

So, I am pretty darn baffled here.

On pagure I see in postgres logs:

2021-11-19 19:31:31.896 GMT [2658401] ERROR:  column "hricky" does not exist at character 34
2021-11-19 19:31:31.896 GMT [2658401] STATEMENT:  select * from users where user = hricky;

Indeed:

pagure=# select * from users where user = 'hricky';                                                 
 id | user | fullname | default_email | password | token | created | updated_on | _settings | refuse_
sessions_before
----+------+----------+---------------+----------+-------+---------+------------+-----------+--------
----------------
(0 rows)

except:

pagure=# select * from users where id = '9556';
  id  |  user  |    fullname    | default_email  | password | token |          created           |   
      updated_on         | _settings | refuse_sessions_before 
------+--------+----------------+----------------+----------+-------+----------------------------+---
-------------------------+-----------+------------------------
 9556 | hricky | Hristo Marinov | hricky@REDACTED |          |       | 2021-02-24 21:46:29.544848 | 20
21-02-24 21:46:29.544848 |           | 
(1 row)

(I redacted the email domain)

What the heck is going on here?

On Fri, Nov 19, 2021 at 07:58:43PM +0000, Kevin Fenzi wrote:

pagure=# select * from users where user = 'hricky';

You need from quotes on that one to make it work, user or users is a reserved
keyword for postgresql (I never know which one so I always end-up putting both
in "")

Many thanks to the Fedora Infrastructure Team! Because of their competence and effort, things are working for me now.

So this one was interesting.

Basically, @hricky had a (long) ssh key stored in FAS and which seem to have remained in IPA's cache despite having been removed from the system about a week ago.
That long ssh key was thus sent to pagure. Pagure would authenticate the user and the whole process would go through, so there was no error showing up anywhere.
However, that key was breaking the storage limit for cookies (ie: it was so large that it went above the maximum amount of data we can store in a cookie). This is similar to the early days, when we were asking for all the groups someone is a member of and authentication broke for some users because they were in too many groups.
Since the key had already been removed from noggin there wasn't much we could do there to help (although we should figure out why it was still cached and sent to pagure.io).

What we ended up doing is: we realized that the ssh key is only ever needed upon login to set-up the user's account on pagure. Once this is done, there is absolutely no need to keep that information in memory and even less to keep it in the cookie. So I've modified pagure to drop the ssh key from its cookie once the user is set-up. That brought back the cookie to a reasonable size and allowed @hricky to stay authenticated to pagure.io.

The upstream PR is at: https://pagure.io/pagure/pull-request/5249 (this is hotfixed on pagure.io)

Note: that may also fix the issue Jeremy had a while back by having multiple ssh keys associated to his account.