Re: [PoC] Federated Authn/z with OAUTHBEARER
От | Thomas Munro |
---|---|
Тема | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Дата | |
Msg-id | CA+hUKG+mUfH81RuYm5fJrOxdm85hvxLEm=KxXm+n-12FJJH9jA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PoC] Federated Authn/z with OAUTHBEARER (Jacob Champion <jacob.champion@enterprisedb.com>) |
Ответы |
Re: [PoC] Federated Authn/z with OAUTHBEARER
|
Список | pgsql-hackers |
On Wed, Mar 5, 2025 at 6:08 AM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > ktruss shows absolutely no syscall activity on the authorization > server during the failing test, because Curl's talking to something > else. sockstat confirms that I completely forgot to listen on IPv6 in > the test server. Dual stack sockets only work from the IPv6 > direction... > > There must be some law of conservation of weirdness, where the > strangest failure modes have the most boring explanations. I'll work > on a fix. Heh, wow, that was confusing :-) Actually I'm still confused (why passing sometimes then?) but I'm sure all will become clear with your patch... > On Mon, Mar 3, 2025 at 8:11 PM Thomas Munro <thomas.munro@gmail.com> wrote: > > I think that is telling us that a non-blocking socket can be in a > > state that is not yet connected enough even to tell you its local > > address? That is, connect() returns without having allocated a local > > address, and does that part asynchronously too? I don't know what to > > think about that yet... > > That is also really good to know, though. So that EINVAL message > might, in the end, be completely unrelated to the bug? (Curl doesn't > worry about the error, looks like, just prints it to the debug > stream.) Yeah. I wonder if it only happens if the connection is doomed to fail already, or something. But I don't plan to dig further if it's harmless (maybe curl shouldn't really do that, IDK).
В списке pgsql-hackers по дате отправления: