search

dylex / postgresql-typed

Haskell PostgreSQL library with compile-time type inference
http://hackage.haskell.org/package/postgresql-typed
Other
83 stars 12 forks source link

Other forms of authentication #5

Closed Zankoku-Okuno closed 7 years ago

Zankoku-Okuno commented 7 years ago

It'd be great to connect to databases using non-password authentication methods. In particular, I almost always use ident. Until I set a password for myself, the compiler was running into

Exception when trying to run compile-time code:
        PGFATAL [28P01]: password authentication failed for user "foo"

I haven't actually gotten a program compiled with this library yet, but I assume something similar would also happen at runtime.

dylex commented 7 years ago

Trust, password, md5 are all supported, as are ident (with the right config), and peer (with postgresql >= 9.1 on *nix). Kerberos/GSS are not (though there's not much demand). Are you using TCP or a local socket? Can psql connect using the same settings?

Zankoku-Okuno commented 7 years ago

I'm TCPing to localhost, and I can connect over ident with psql (among other things).

I don't see any of those options in PGDatabase, so now I'm wondering what part of the API am I overlooking?

dylex commented 7 years ago

The authentication mechanism in postgresql is driven by the server -- you can't configure it from clients. The only thing you configure is where to connect to (IP/socket), the database name, and the username, and then the server decides whether to ask for a password or something else. For ident and peer (as of postgresql 9.1), it doesn't ask for anything. If it's saying password authentication failed, then it means the server is asking for a password, which suggests that ident already failed or isn't being initiated for some reason, based on the user, database, and IP in pg_hba.conf.

When I set up oidentd just now to test this, it didn't work the first time because "localhost" (the default host) was resolving to IPv6, and oidentd only supports ipv4, but changing it to 127.0.0.1 seemed to work fine. Not sure if you're seeing something like that, perhaps.

Zankoku-Okuno commented 7 years ago

Ok, things are starting to make sense now.

I had assumed previous versions of my code (using postgresql-simple) were connecting over localhost, when in fact that library tries to find and use a socket by default. So, it turns out I wasn't connecting on localhost at all.

Thanks for the pointers. I'm going to go ahead and close.

That said, now that I've looked deeper at everything, I'm curious why you chose not to use libpq's connection string style of configuration?

dylex commented 7 years ago

postgresql-typed doesn't use libpq, so using a string-based configuration seemed unnecessary and un-haskelly, but providing a compatibility string -> config parser might not be the worst idea.