Add withdraw authorization command in auth interface #992
Conversation
Pietfried
force-pushed
the
refactor/auth-module-mutex-usage
branch
2 times, most recently
from
564c9ec to
887138e
Compare
Pietfried
force-pushed
the
feature/978-withdraw-authorization
branch
3 times, most recently
from
1a9c491 to
692e61a
Compare
Pietfried
requested review from
corneliusclaussen and
hikinggrass
as code owners
| std::mutex event_mutex; | ||
| std::mutex withdraw_mutex; |
There was a problem hiding this comment.
this could probably also use the event_mutex now, or am I mistaken?
There was a problem hiding this comment.
Initially I thought so too. If we only use the event_mutex multiple withdraw requests could run in parallel and they could override this->withdraw_request in that case, because the event_mutex is released here while waiting for the targeted processing threads to finish. It ensures that only one withdraw_request can run at a time. Since a withdraw request should not block for a significant amount of time this seems to be the best solution to me
Pietfried
force-pushed
the
feature/978-withdraw-authorization
branch
2 times, most recently
from
adc0be8 to
7dac05d
Compare
Pietfried
force-pushed
the
feature/978-withdraw-authorization
branch
from
53d86a8 to
929afb3
Compare
Pietfried
force-pushed
the
feature/978-withdraw-authorization
branch
3 times, most recently
from
f382707 to
227ba77
Compare
modules/Auth/Auth.cpp
Outdated
| @@ -19,10 +19,8 @@ void Auth::init() { | |||
| this->info.id, (!this->r_kvs.empty() ? this->r_kvs.at(0).get() : nullptr)); | |||
|
|
|||
| for (const auto& token_provider : this->r_token_provider) { | |||
| token_provider->subscribe_provided_token([this](ProvidedIdToken provided_token) { | |||
| std::thread t([this, provided_token]() { this->auth_handler->on_token(provided_token); }); | |||
There was a problem hiding this comment.
I think this change means that we can handle only one token at a time. We do have for example setups where we have 2 sockets and each socket has a own rfid card reader (so the customers should be able to start sessions simultaneously)
There was a problem hiding this comment.
The handlers are running in their own thread as long as the tokens are published from different token_providers. If tokens are published from the same provider you are right though, the handlers will only be executed once the previous one has returned. I will therefore change it back.
Pietfried
force-pushed
the
feature/978-withdraw-authorization
branch
2 times, most recently
from
cc20775 to
9c439c3
Compare
* added operator overloading for ProvidedIdToken and IdToken types * Changed tokens_in_process from set of strings to set of ProvidedIdToken to be able to access the referenced connectors * Introduced processing_finished_cv in AuthHandler to be able to notify a withdraw request waiting thread that the processing of a token has finished * Implemented handle_withdraw_authorization function * Added test cases for new functionality * Move Deuathorized event in EvseManager so that its only published in case session is currently active Signed-off-by: Piet Gömpel <[email protected]> Signed-off-by: Maaike Zijderveld, iolar <[email protected]>
…ken in Auth module Signed-off-by: Piet Gömpel <[email protected]>
Pietfried
force-pushed
the
feature/978-withdraw-authorization
branch
from
9c439c3 to
918d79d
Compare
In our case, we only provide a Auth interface, thus we simply need to add the stub handler and return a meaningful/error value. Signed-off-by: Michael Heimpold <[email protected]>
Describe your changes
This PR adds a
withdraw_authorizationcommand in theauthinterface and the Auth module.Issue ticket number and link
#978
Checklist before requesting a review