Re: Design Considerations for New Authentication Methods
От | Magnus Hagander |
---|---|
Тема | Re: Design Considerations for New Authentication Methods |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCEA0FCEF@algol.sollentuna.se обсуждение исходный текст |
Ответ на | Re: Design Considerations for New Authentication Methods ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: Design Considerations for New Authentication Methods
|
Список | pgsql-hackers |
> >> ... Why would we reject a piece of useful functionality based on a > >> published standard? > > > > Well, size and maintainability of the proposed patch are certainly > > factors in any such decision. As a closely related example, I bet > > we'd have rejected the original Kerberos-support patch if > we'd known > > then what we know now. It's been a constant source of bugs > ever since > > it went in, and with so few users of the feature, it takes > a long time > > to find the problems. > > To be honest, I have often wondered *why* we support kerberos > outside of the uber l33t geek factor. I have not once in a > commercial deployment had a business requirement for the > beast. LDAP? Now that is a whole other issue :) Single sign-on in a Windows/AD environment (I'm talking clients on windows, servers on linux here - at least in my case). I know several people who use it, most just don't post here ;-) Now, it would likely be a lot *easier* to do this with GSSAPI than the pure kerberos stuff we have now, given that the Windows native APIs support GSSAPI compatible stuff, but not the stuff we have now. //Magnus
В списке pgsql-hackers по дате отправления: