diff options
| author | Ade Lee <alee@redhat.com> | 2017-05-24 11:15:03 -0400 |
|---|---|---|
| committer | Ade Lee <alee@redhat.com> | 2017-05-24 12:34:13 -0400 |
| commit | 1d6860b20970dae43b81e9f943fb49575f377099 (patch) | |
| tree | 2cb0fbdeb0811093cf845a527cab69a6a287639d /base/common/python | |
| parent | de9f890133e3acc660b985e8ef5950507d341a03 (diff) | |
| download | pki-1d6860b20970dae43b81e9f943fb49575f377099.tar.gz pki-1d6860b20970dae43b81e9f943fb49575f377099.tar.xz pki-1d6860b20970dae43b81e9f943fb49575f377099.zip | |
Simplify recovery audit logging
Currently, when we use the retrieveKey() REST interface, there are
two logs generated for the processing of a recovery request. To
rectify this, logging has been removed from the lower level in the
SecurityDataProcessor and is delegated to the higher level.
This necessitated adding audit logging to the SecurityDataRecoveryService,
which processes recovery events asynchronously.
In addition, the logging in retrieveKey() has been pushed down to
the retrieveKeyImpl, because there is at least one success exit point in
retrieveKeyImpl where a recovery request is created, but no key is exported.
Hence in this case, a KeyRetrieve success event is not warranted.
Change-Id: I0725e6fe82046ae666bf6c81d6a6ba58261dfc87
Diffstat (limited to 'base/common/python')
0 files changed, 0 insertions, 0 deletions