Re: Design Considerations for New Authentication Methods

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Design Considerations for New Authentication Methods
Date: 2006-11-01 14:33:22
Message-ID: 20061101143322.GJ24675@kenobi.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Henry B. Hotz (hotz(at)jpl(dot)nasa(dot)gov) wrote:
> I've been looking at adding SASL or GSSAPI as an auth method. I have
> some questions about how to handle the flow of control changes.

Great! I'd love to see that implemented, personally, so if you're
looking for help, please let me know.

> round trips and network accesses done. I notice that all the
> authentication (pg_fe_sendauth()) is done inside PWConnectPoll(),
> which sounds like something that isn't expected to block on network
> access.

I think you're missing a bit about how the design works.
PGConnectPoll() is expected to be called multiple times until the
connection is established. Basically, you can return something to the
user that says "connection not done yet, but I'm returning because you
said to not block. Please call again when more data available or you
have the opportunity to". This is a pretty common arrangment when
non-blocking systems are implemented. As Tom said, you should just need
to have some state stored so that you know what's going on when you're
called again.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-11-01 14:50:56 Re: [HACKERS] WAL logging freezing
Previous Message Stephen Frost 2006-11-01 14:26:04 IN(subselect returning few values ...)