Add support for specifing an explicit GSSAPI mech #19
Conversation
|
Looking forward to seeing this support added as we are coming from the same common need. |
|
Have been scratching my head wondering why authentication was failing but this solved my issue! Thank you! |
|
@frozencemetery this sounds reasonable to me |
|
@simo5 Have you changed your mind from your comment on #18 (comment) then? |
|
Even if the go library is poor, this pull request is just to add some more flexibility into the requests-gssapi library that might be useful for other purposes and can be ignored in most cases where not needed. It would be useful to have this merged/released anyway. |
Btw, no I have not changed idea, but allowing to specify a mechanism is not endorsing another library, and has other uses, including testing that it can apply to, so I think this request is worth considering. |
|
I was doing some more work on this yesterday, and found a viable workaround which does not require this PR being merged, so I'll leave it up to you whether you want to merge or abandon. I'll post details on #18. |
|
Alright. I'd misinterpreted your comment as an objection to this functionality. I have no objection either. @optiz0r would you mind fixing the code to pass CI? Looks like flake errors. |
|
please |
Add support for passing an explicit mech through to gssapi's `SecurityContext` constructor. This allows overriding the auto-detected mechanism, and enabling support for RFC4178 SPNEGO. Fixes pythongssapi#18
optiz0r
force-pushed
the
fix18_explicit_mech
branch
from
efa1be2
to
ddcec4f
Compare
|
Thanks for updating. Github doesn't notify me when you do that (though I think that might have finally changed). Working on this now. |
|
Pushed to master as c9e429c |
Add support for passing an explicit mech through to gssapi's
SecurityContextconstructor. This allows overriding the auto-detectedmechanism, and enabling support for RFC4178 SPNEGO.
Fixes #18