Thread: Massively annoying bug still not fixed in v1.20 :-(
<span style="font-family: Arial; font-size: 13px;">I always connect to PostgreSQL over an SSH tunnel. As such, I have noneed for a special password for the PostgreSQL server, as it's already over a SSH tunnel. I assume this is how 99% of allusers do things.<br /><br />Why, then, does it need to ask me every single time for a password, even though I have checkedthe "remember password" a billion times by now? It's actually pre-checked, yet keeps asking for the damn passwordevery single time. It really adds up and becomes insanely annoying after the millionth time.<br /><br />Please fixthe bug where it asks and ask for a password even when you have checked the checkbox to remember the (empty) password.<br/></span>
On Fri, Dec 19, 2014 at 1:45 PM, <hushthatbush@hushmail.com> wrote: > I always connect to PostgreSQL over an SSH tunnel. As such, I have no need > for a special password for the PostgreSQL server, as it's already over a SSH > tunnel. I assume this is how 99% of all users do things. > > Why, then, does it need to ask me every single time for a password, even > though I have checked the "remember password" a billion times by now? It's > actually pre-checked, yet keeps asking for the damn password every single > time. It really adds up and becomes insanely annoying after the millionth > time. > > Please fix the bug where it asks and ask for a password even when you have > checked the checkbox to remember the (empty) password. It's not going to work because when using an SSH tunnel we have to use a random port number for the client end of the tunnel. When libpq (not pgAdmin) tries to match the connection details against those that are stored, it will often fail because the port number won't match. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 12/19/2014 09:51 PM, Dave Page wrote: > It's not going to work because when using an SSH tunnel we have to use > a random port number for the client end of the tunnel. When libpq (not > pgAdmin) tries to match the connection details against those that are > stored, it will often fail because the port number won't match. Why not handle it like libpq does? Connect, and if the server asks for a password *then* prompt the user. You can do this with a libpq connection callback. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Dec 19, 2014 at 3:11 PM, Craig Ringer <craig@2ndquadrant.com> wrote: > On 12/19/2014 09:51 PM, Dave Page wrote: >> It's not going to work because when using an SSH tunnel we have to use >> a random port number for the client end of the tunnel. When libpq (not >> pgAdmin) tries to match the connection details against those that are >> stored, it will often fail because the port number won't match. > > Why not handle it like libpq does? > > Connect, and if the server asks for a password *then* prompt the user. That's what does happen. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 12/19/2014 11:24 PM, Dave Page wrote: > That's what does happen. Oh, I see, but the password matching for caching doesn't work. IIRC pgadmin creates a pgpass file, right? So to do this for ssh tunnels you'd have to dynamically add entries (ugly) or change use of .pgpass to instead use a callback within pgadmin . -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Dec 19, 2014 at 3:37 PM, Craig Ringer <craig@2ndquadrant.com> wrote: > On 12/19/2014 11:24 PM, Dave Page wrote: >> That's what does happen. > > Oh, I see, but the password matching for caching doesn't work. > > IIRC pgadmin creates a pgpass file, right? So to do this for ssh tunnels > you'd have to dynamically add entries (ugly) or change use of .pgpass to > instead use a callback within pgadmin . Right - we'd have to store the entries somewhere based on the target server and the SSH config, and dynamically rebuilt the pgpass file during the connection process. That seems a) ugly and b) very fragile. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 12/19/2014 11:57 PM, Dave Page wrote: > Right - we'd have to store the entries somewhere based on the target > server and the SSH config, and dynamically rebuilt the pgpass file > during the connection process. That seems a) ugly and b) very fragile. Darn. I thought libpq had a callback for a password prompt, but it doesn't. Guess we should add that. If libpq gets an auth request from the server and has no password from the connection string, it should invoke a callback (if supplied) that lets the client supply a password dynamically. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Dec 19, 2014 at 4:02 PM, Craig Ringer <craig@2ndquadrant.com> wrote: > On 12/19/2014 11:57 PM, Dave Page wrote: >> Right - we'd have to store the entries somewhere based on the target >> server and the SSH config, and dynamically rebuilt the pgpass file >> during the connection process. That seems a) ugly and b) very fragile. > > Darn. I thought libpq had a callback for a password prompt, but it doesn't. > > Guess we should add that. If libpq gets an auth request from the server > and has no password from the connection string, it should invoke a > callback (if supplied) that lets the client supply a password dynamically. That would be very handy. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
<p dir="ltr"><br /> On Dec 19, 2014 5:02 PM, "Craig Ringer" <<a href="mailto:craig@2ndquadrant.com">craig@2ndquadrant.com</a>>wrote:<br /> ><br /> > On 12/19/2014 11:57 PM, DavePage wrote:<br /> > > Right - we'd have to store the entries somewhere based on the target<br /> > > serverand the SSH config, and dynamically rebuilt the pgpass file<br /> > > during the connection process. That seemsa) ugly and b) very fragile.<br /> ><br /> > Darn. I thought libpq had a callback for a password prompt, but itdoesn't.<br /> ><br /> > Guess we should add that. If libpq gets an auth request from the server<br /> > and hasno password from the connection string, it should invoke a<br /> > callback (if supplied) that lets the client supplya password dynamically.<br /> ><p dir="ltr">We definitely should. And we should make sure we design it not to justsupport passwords but anything we might need to unlock an authentication - say a x509 certificate (doesn't have to bethe same function, but it should be part of the design considerations for the feature). <p dir="ltr">/Magnus <br />
On Dec 19, 2014 5:02 PM, "Craig Ringer" <craig@2ndquadrant.com> wrote:
>
> On 12/19/2014 11:57 PM, Dave Page wrote:
> > Right - we'd have to store the entries somewhere based on the target
> > server and the SSH config, and dynamically rebuilt the pgpass file
> > during the connection process. That seems a) ugly and b) very fragile.
>
> Darn. I thought libpq had a callback for a password prompt, but it doesn't.
>
> Guess we should add that. If libpq gets an auth request from the server
> and has no password from the connection string, it should invoke a
> callback (if supplied) that lets the client supply a password dynamically.
>We definitely should. And we should make sure we design it not to just support passwords but anything we might need to unlock an authentication - say a x509 certificate (doesn't have to be the same function, but it should be part of the design considerations for the feature).
/Magnus
It might also want the PQconninfoOption array, but it can get that from PQconninfo(PGconn*).
It's unfortunately necessary to consider that on certain platforms (ahem Windows ahem) the callback function might be running in a module linked to a different C library - so it's not safe to free() memory within libpq that was malloc()'d within the callback. We can solve that by exposing a PQmalloc(...) and declaring that memory allocated as a callback result must use that function. We already have PQfreemem(...) for the opposite direction so that seems to be the way to go, calling it PQallocmem(...) .
PostgreSQL Development, 24x7 Support, Training & Services