Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug][Satosa] Default request and response routing logic is flipped #246

Closed
Zicchio opened this issue Aug 8, 2024 · 1 comment · Fixed by #253
Closed

[Bug][Satosa] Default request and response routing logic is flipped #246

Zicchio opened this issue Aug 8, 2024 · 1 comment · Fixed by #253

Comments

@Zicchio
Copy link
Collaborator

Zicchio commented Aug 8, 2024

According to the interface specification, the RequestHandler interface https://github.com/italia/eudi-wallet-it-python/blob/dev/pyeudiw/satosa/interfaces/request_handler.py defines the creation of the Request Object

This endpoint is called by the User-Agent/Wallet Instance to retrieve the signed signed Request Object.

But the default realization delegates this behaviour to the ResponseHandler default implementation https://github.com/italia/eudi-wallet-it-python/blob/dev/pyeudiw/satosa/default/response_handler.py

Likewise, the interface ResponseHandler interface https://github.com/italia/eudi-wallet-it-python/blob/dev/pyeudiw/satosa/interfaces/request_handler.py should process the /authorize response

This endpoint is called by the User-Agent/Wallet Instance after the user has been authenticated.
but this behaviour is actually delegated to the RequestHandler default realization https://github.com/italia/eudi-wallet-it-python/blob/dev/pyeudiw/satosa/default/request_handler.py

Confronting the python docstring with the eudi it wallet specification suggest that the interface definition and docstring are correct, and the implementations are erroneously flipped.

@peppelinux
Copy link
Member

Resolved by #253

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants