On Wed, Jul 22, 2009 at 8:57 AM, Magnus Hagander wrote:
> On Wed, Jul 22, 2009 at 14:53, Tom Lane wrote:
>> Magnus Hagander writes:
Yup, you would need a protocol change that would allow the client to
change its mind about what the username was after it got the auth
challenge. And
On Wed, Jul 22, 2009 at 14:53, Tom Lane wrote:
> Magnus Hagander writes:
>>> Yup, you would need a protocol change that would allow the client to
>>> change its mind about what the username was after it got the auth
>>> challenge. And then what effects does that have on username-sensitive
>>> pg_
Magnus Hagander writes:
>> Yup, you would need a protocol change that would allow the client to
>> change its mind about what the username was after it got the auth
>> challenge. And then what effects does that have on username-sensitive
>> pg_hba.conf decisions? We go back and change our minds
On Tue, Jul 21, 2009 at 16:06, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Jul 21, 2009 at 15:58, Tom Lane wrote:
>>> Are you not describing a behavior that you yourself removed in 8.4,
>>> ie the libpq code that looked aside at Kerberos for a username?
>
>> Yes, partially I am :-)
>
>> B
Am Dienstag, 21. Juli 2009 16:01:01 schrieben Sie:
> Doing it on the client presents a certain challenge when it comes to
> certificates for example - or really in any case where you need to map
> the username to something else. It would be quite convenient to have
> that ability controlled from th
Magnus Hagander writes:
> On Tue, Jul 21, 2009 at 15:58, Tom Lane wrote:
>> Are you not describing a behavior that you yourself removed in 8.4,
>> ie the libpq code that looked aside at Kerberos for a username?
> Yes, partially I am :-)
> But it was not documented, and done in a fairly hackish w
On Tue, Jul 21, 2009 at 15:58, Tom Lane wrote:
> Magnus Hagander writes:
>> That said, if there is a username specified it should not be ignored.
>> But if there is none specified, it should work. This works "reasonably
>> well" today, in that we pick the username up from the environment. But
>> I
Magnus Hagander writes:
> That said, if there is a username specified it should not be ignored.
> But if there is none specified, it should work. This works "reasonably
> well" today, in that we pick the username up from the environment. But
> I can see cases where it would be a lot more useful to
Sorry for jumping late into this discussion, but I've been out sailing
for a couple of weeks and stayed away from email :-)
On Mon, Jun 29, 2009 at 21:01, Stephen Frost wrote:
> * Lars Kanis (ka...@comcard.de) wrote:
>> The problem I have, is that I want to use an ordinary windows application,
>>
> # MAPNAME SYSTEM-USERNAMEPG-USERNAME EFFECTIVE-USERNAME
> gssapi-user/^(.*)@domain\.com$simple-role \1
> gssapi-user/^use...@domain\.com$ super-roleuser_a
> gssapi-user/^use...@domain\.com$ super-roleuser_c
My fault. The lower lines should be:
gssapi-us
Am Montag, 29. Juni 2009 18:12:13 schrieben Sie:
> Lars Kanis writes:
> > The problem I have, is that I want to use an ordinary windows
> > application, which connects to an arbitrary ODBC data source. This
> > application stores a fixed username und password for the connection
> > within it's own
Lars,
* Lars Kanis (ka...@comcard.de) wrote:
> The problem I have, is that I want to use an ordinary windows application,
> which connects to an arbitrary ODBC data source. This application stores a
> fixed username und password for the connection within it's own binary data
> file. It doesn't
Lars Kanis writes:
> The problem I have, is that I want to use an ordinary windows application,
> which connects to an arbitrary ODBC data source. This application stores a
> fixed username und password for the connection within it's own binary data
> file. It doesn't know anything about TLS-co
Am Montag, 29. Juni 2009 16:26:56 schrieben Sie:
> Lars Kanis writes:
> > this patch adds the possibility to map the login-rolename to a different
> > rolename actually used for permissions.
>
> This seems like an ugly addition with a very narrow use case. Can't
> you accomplish what you want wit
Lars Kanis writes:
> this patch adds the possibility to map the login-rolename to a different
> rolename actually used for permissions.
This seems like an ugly addition with a very narrow use case. Can't
you accomplish what you want with the existing usermap facility?
r
15 matches
Mail list logo
