Handle all exceptions

[nsklikas]

I encounter a bug were the exception defined in https://github.com/IdentityPython/oidc-op/blob/master/src/oidcop/token/__init__.py#L117 was raised when I was trying to exchange an authorization code for an access token.

Perhaps we should handle all exceptions there? Or simply create an OidcopError exception from which all other exceptions will inherit and we can simply catch that?

What do you think?

Closes #97

[rohe]

As you can see in oidcop/exception.py the idea was that there would be a package specific exception which all the exceptions in that package inherited from.
Now OidcEndpointException should probably be renamed to OidcOPException/OidcOPError and possible package exception that wasn't following that pattern should be hunted down and made to comply.

[rohe]

Having said that we still will have exception that belong to OidcMsg and CryptoJWT that will crop up in OidcOP.

[peppelinux]

Can you share the test that make this exception?
I'm interested about why this exception was not handled by unit tests

[nsklikas]

Ok I looked some more into it and it seems that the bug is elsewhere.

I try to run a regular code flow. When I try to exchange the authorization code with an access_token the following error is raised:

  File "/srv/venv/lib/python3.7/site-packages/oidcop/oauth2/token.py", line 407, in process_request
    _access_token, grant=True
  File "/srv/venv/lib/python3.7/site-packages/oidcop/session/manager.py", line 459, in get_session_info_by_token
    _token_info = self.token_handler.info(token_value)
  File "/srv/venv/lib/python3.7/site-packages/oidcop/token/handler.py", line 55, in info
    _handler, item_info = self.get_handler(item, order)
  File "/srv/venv/lib/python3.7/site-packages/oidcop/token/handler.py", line 75, in get_handler
    res = self.handler[typ].info(token)
  File "/srv/venv/lib/python3.7/site-packages/oidcop/token/__init__.py", line 117, in info
    raise WrongTokenClass(_res["token_class"])
oidcop.token.exception.WrongTokenClass: access_token

The bug is cause from the token minting. In

oidc-op/src/oidcop/session/grant.py

Line 306 in 0f92cfb

item.value = token_handler(session_id=session_id, **token_payload)

it calls Token without passing the token_class. The function called is

oidc-op/src/oidcop/token/__init__.py

Line 74 in 0f92cfb

def __call__(self, session_id: Optional[str] = "", token_class: Optional[str] = "", **payload) -> str:

Which expects a token_class and if it isn't present then it defaults to authorization_code. It's weird that we haven't stumble on it all this time.

[nsklikas]

Having said that we still will have exception that belong to OidcMsg and CryptoJWT that will crop up in OidcOP.

To solve this we can have a common exception base that will be shared across the libraries, e.g.:

OIDCError
OidcMsgError(extends OIDCError)
CryptoJWTError(extends OIDCError)
OidcOPError(extends OIDCError)

OIDCError could live in any of these modules (perhaps oidc-msg is the most appropriate?)

[rohe]

Part of this is dealt with in #99 .

[rohe]

If we add OidcError to oidcmsg it will not cover CryptoJWT but I don't see that as a major problem.
Actually I think it's the right way to go.

[peppelinux]

@nsklikas overall It LGTM, so here my approval. Please fill evetually the remaining gaps, It seems that @rohe told us something ..