[
https://issues.apache.org/jira/browse/PHOENIX-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632049#comment-16632049
]
Lev Bronshtein commented on PHOENIX-4688:
-----------------------------------------
{quote}'m not sure if should be reading this with incredulity :). {{brew
install krb5}}, and modification of PATH to put those first is all that needs
to be done. My point is that assuming that all users of OSX are using Heimdal
is wrong. However, I don't know of a way to differentiate between MIT and
Heimdal at a glance. That said...
{quote}
I am not a very advanced Mac user, I find changing a lot of default behavior
painful, but that could be my experience
{quote}Any reason we have to generate two different krb5.conf at all? If we can
generate a single krb5.conf that works for Heimdal and MIT, we don't need to
have this indirection, right?
{quote}
We would have to teach Kirby (?) how to do that I suspect. I am not sure if
this is that important for the scope of the test especially given that this is
not an issue in future version of Heimdal
{quote}And, to be clear, the alternative is to use python-gssapi instead of the
hacked requests-kerberos?
{quote}
Sadly no. The reason I was pointed to python-gssapi is that it seem that the
community is trying to deprecate python-kerberos and requests-kerberos (seems
as it ios relagted to maintenance). However requests-gssapi does not support
SPNEGO (i.e. it does not send the SPNEGO Mec OID)
See [https://github.com/requests/requests-kerberos/issues/116] for discussion,
I since closed the issue and the associated PR as I in the 4.x branch
CALCITE-1922 seemed to be working, but now it once again appears to be broken
as evidenced by this stack trace
{quote}911 at
sun.security.jgss.GSSCredentialImpl.getElement(GSSCredentialImpl.java:600)
912 at
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:317)
913 at
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
*914 at
org.eclipse.jetty.security.SpnegoLoginService.login(SpnegoLoginService.java:138)
<-- This should call
org.apache.calcite.avatica.server.[PropertyBasedSpnegoLoginService.java|https://github.com/apache/calcite-avatica/pull/15/files?utf8=%E2%9C%93&diff=split#diff-dd280db9e5949206ab19d453d55e4f59]*
915 at
org.eclipse.jetty.security.authentication.LoginAuthenticator.login(LoginAuthenticator.java:61)
916 at
org.eclipse.jetty.security.authentication.SpnegoAuthenticator.validateRequest(SpnegoAuthenticator.java:99)
917 at
org.apache.calcite.avatica.server.AvaticaSpnegoAuthenticator.validateRequest(AvaticaSpnegoAuthenticator.java:43)
{quote}
It might be an error on my part as well. However if this worked we could
easily have transitioned to requests-gssapi.
So the options are
# Get to the bottom of CALCITE-1922 not working issue – I spent quite a bit of
time there and it seems like it should just work
# Add SPNEGO support to requests-gsspi or python-gssapi
[https://github.com/pythongssapi/python-gssapi/issues/50] no work has been done
so far
# Hack up requests-kerberos in
[https://github.com/requests/requests-kerberos/issues/116] I specified what the
problem , was bus as CALCITE-1922 was working I closed it saying that this is
die to a pedantic Jetty configuration and is no longer an issue, however I
could reopen, but do not have much hope for a resolution or at least one that
will happen soon.
> Add kerberos authentication to python-phoenixdb
> -----------------------------------------------
>
> Key: PHOENIX-4688
> URL: https://issues.apache.org/jira/browse/PHOENIX-4688
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Lev Bronshtein
> Priority: Minor
>
> In its current state python-phoenixdv does not support support kerberos
> authentication. Using a modern python http library such as requests or
> urllib it would be simple (if not trivial) to add this support.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
