Le mercredi 27 juin 2012 14:54:15, Magnus Hagander a écrit : > When debugging strange and complex pg_hba lines, it can often be quite > useful to know which line is matching a particular connection that > failed for some reason. Because more often than not, it's actually not > using the line in pg_hba.conf that's expected. > > The easiest way to do this is to emit an errdetail for the login > failure, per this patch. > > Question is - is that leaking information to the client that we > shouldn't be leaking?
I fear it is exactly the problem. Too bad because the feature is interesting. > And if it is, what would be the preferred way to deal with it? We > could put that as a detail to basically every single error message > coming out of the auth system, but that seems like a bad idea. Or we > could make a separate ereport(LOG) before send it to the client, > perhaps? The problem is also that 1/ you're not sure how you did connect exactly 2/ you're not connecting like you wanted to do. (my case with ipv4 vs ipv6 just below). Providing more information on what we receive from client and tell it to the client sounds good, no ? > Thoughts? I just consume some moment before fixing an ipv6 vs ipv4 login failure. The matched line from pg_hba .conf would have been very useful. Maybe it is enough to report what happens on the connection: from which host, TCP/socket (and which one, given that we should have multiple option here soon), dbname, user, .... inspecting pg_hba.conf will remain difficult if map is used or some other +group option. -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
