Export `load` and `verify_signature` from `.api` in main module about pyjwt HOT 8 CLOSED

...but those were never part of the public (documented) API, right?

I think if this functionality makes sense to expose (can you elaborate on the use case?) it will need some big fat "this is possibly unsafe" warnings and preferably also corresponding names, e.g. unsafe_load() and so on.

from pyjwt.

What @wbolster said.

from pyjwt.

Ah, I see that they weren't, in fact, in __all__, even in 0.4.1 where they were in the package main module.

The use case is, I think, not uncommon. I serve multiple issuers. I need to inspect the issuer before I know which secret to use. On the other hand, this is just premature optimization where I'm trying to avoid the base64 decode when it comes time to verify.

Up to you all, then. I'm happy to submit a patch, with whatever scary names you think are appropriate, if it seems reasonable to make these public. Otherwise, no big deal.

from pyjwt.

I'm still not sure this should be public API, unless we have others interested in it being it. For now, you'll still be able to import it directly from jwt.api.

from pyjwt.

Yep. Closing. If more people come across this they can speak up if they want it.

from pyjwt.

I have the same need as @tilgovi: verifying jwt's received from multiple issuers, with a different key per issuer. Thus I need to get the issuer out of the jwt in order to pass in the appropriate key for verification.

from pyjwt.

I think it makes sense to expose an API for this.

As for safety for the user and bw-compat what if there were a keyword argument for decode that returned the parts tuple and we just exposed verify but not load?

(payload, signing_input, header, signature) = decode(..., verify=False, parts=True)
if verify(payload, signing_input, header, signature) ...

That way, verify=False would have to be the explicit opt-in rather than trying to come up with a "safe" name for load?

from pyjwt.

OTOH, I don't like when functions have multiple return types.

from pyjwt.