FAS login occasionally fails with HTTP 400. #13280
Labels
No labels
announcement
anubis
authentication
aws
backlog
blocked
bodhi
ci
cloud
communishift
copr
database
day-to-day
dc-move
deprecated
dev
discourse
dns
downloads
easyfix
epel
firmitas
forgejo_migration
Gain
High
Gain
Low
Gain
Medium
gitlab
greenwave
hardware
help wanted
high-trouble
koji
koschei
lists
low-trouble
medium-trouble
mirrorlists
monitoring
Needs investigation
odcs
OpenShift
ops
outage
packager_workflow_blocker
pagure
permissions
Priority
Needs Review
Priority
Next Meeting
Priority
🔥 URGENT 🔥
Priority
Waiting on Assignee
Priority
Waiting on External
Priority
Waiting on Reporter
rabbitmq
release-monitoring
releng
request-for-resources
s390x
security
SMTP
sprint-0
sprint-1
src.fp.o
staging
unfreeze
waiverdb
websites-general
wiki
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
No milestone
No project
No assignees
7 participants
Notifications
Total time spent: 20 minutes
Due date
rokejulianlockhart
20 minutes
No due date set.
Dependencies
No dependencies set.
Reference
infra/tickets#13280
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description of request
At
id.fedoraproject.org/openidc/Continue?ipsilon_transaction_id=88cb46e1-8b98-4f74-82b9-82135336eccb, as I frequently do, I observed the undermentioned, upon attempted, unsuccessful login:I've yet to acquire HAR, because it rarely occurs consequtively, despite frequently recurring. Regardless, this has been previously reported elsewhere, many times:
issues/12294issues/12715issues/12534However, no tickets, since the transferral from Pagure, remain open, to track this.
My Environment
We see this occasionally, where it fixes itself if you go back and try again ... and it maybe happens more often if you leave the window open before doing the FAS authentication.
Nobody really knows why, and we're hoping that it'll get fixed as part of the migration to keycloak (hopefully soon, post freeze, now). I can leave this issue open for a bit.
@james, thanks. I shall link this to
issues/13188, then.In retrospect, the undermentioned is irrelevant:
Strangely, I've had the error page also cause:
crash-stats.mozilla.org/report/index/76e72c01-153f-4ba2-a629-8cb910260515crash-stats.mozilla.org/report/index/4ed413c3-6df3-4978-9979-96ceb0260515crash-stats.mozilla.org/report/index/73f72c59-1d4c-4c23-9ea3-d631b0260515…if at all relevant!
This recently occurred, at
id.fedoraproject.org/saml2/SSO/Continue?ipsilon_transaction_id=b766d92d-002c-4da0-9526-fddf8881fc38:…when attempting to authenticate at
pagure.io/login/?next=https://pagure.io/ipsilon/issue/398.bugzilla.mozilla.org/show_bug.cgi?id=2051153#c3andbugzilla.mozilla.org/show_bug.cgi?id=2051153#c3made this difficult to diagnose:However, because I couldn't get the entire flow to reproduce the failure (although
ipsilon_transaction_id=870287d6-9603-4741-805b-35f51abda1d8occurred soon afterward), even the-jsconsoledidn't assist — I solely observe a request for the FAS logo:My Environment
The Output Of
about:support, at./attachments/1 2codeberg.org/forgejo/forgejo/issues/13259↩︎codeberg.org/forgejo/forgejo/issues/13260↩︎I hit the same error just now. It's a very common problem, at least for me.
I think we figured out what this problem was and have worked around it.
If any of you still see it, please let us know.
@kevin, unfortunately, this continues to consistently reproduce on every first login:
It happened to me ~1 hour ago too
sigh. I had to reboot one of the backends and you may have testing right when it rebooted.
Can you try again now?
ok, next question: Do you have 'advanced tracking protection' enabled? If you disable it does the problem go away?
@kevin,
about:configreturns:…whereas
about:preferences#etpCustomize:~:text=Customize%20tracking%20protectionreturns:Additionally, I attempted to acquire HAR again, but it ceased to reproduce, again! 1
/attachments/0203651b-5fd4-4afe-9179-4531ebc69105↩︎I use the defaults that come with my https://zen-browser.app/ but I have many, many
trackingprotectionrelated settings in myabout:config. I'll try to disable them and see.Was getting that "400 – Bad Request" when trying to FAS login in on https://bodhi.fedoraproject.org/updates/FEDORA-2026-2551d0d66b and https://src.fedoraproject.org/rpms/python-ase
Tried from both Google Chrome (Version 150.0.7871.186 (Official Build) (64-bit)) and Firefox (153.0.1), also in private windows.
Made 5 failed attempts, then cleaned all https://src.fedoraproject.org cookies, and succeeded to login onto it after two more failed attempts in Google chrome.
Hey folks. I have spent a few hours on this, I think I may know where it's coming from. I think it's a bug in Ipsilon.
Ipsilon defines pages as objects, which are exposed by CherryPy. However, in
ipsilon.login.common.LoginFormBase, it stores the current transaction as an instance variable inself.trans. I think this object gets overwritten if another login happens in parallel, because this does not look thread-safe. As a result the transaction id does not match the cookie anymore and is considered invalid.I'll keep looking at this tomorrow and attempt to fix it, but I wanted to write this down here so others know we're working on it (and I don't forget everything on Monday ;-) )
I've set
mod_wgito 1 thread only (and added 2 processes to compensate). Let's see if it helps.Oops. I ran playbooks and I think it overrode your changes. ;( Sorry about that...
No worries, I've put it back.
I'll commit it to ansible too because we should probably observe this for a few days / week(s).
OK I think that fixed the issue. Of course the proper fix would be to have Ipsilon use thread-local variables instead of class attributes, using for example
cherrypy.thread_data, but that would be a much larger change that would impact multiple places in Ipsilon and should be properly tested. For now, I think using processes instead of threads is sufficient, as we plan to replace Ipsilon soonish.If the problem happens again, please reopen this ticket.
@abompard, has a ticket been submitted for that?