[GT-184] Add support for renewing API credentials #464
Conversation
Sae126V
force-pushed
the
GT-184-Extend-API-Credential-Management-to-handle-periodic-renewal
branch
3 times, most recently
from
5728cd9
to
6f26459
Compare
| // This would probably be the place hook for any future policy acceptance tracking | ||
| if (($user->getId() != $authEntity->getUser()) || $isRenewalRequest) { | ||
| $authEntity->setLastRenewTime(); | ||
| } |
There was a problem hiding this comment.
As future work, we should probably always update the renewal time when an API credential is edited, regardless of whether the editing user is the owning user or not, which I think would simplify the logic here.
@Sae126V, could you open an issue for this?
| //If the entity is of type OIDC subject, do a more thorough check again | ||
| if ( | ||
| $type == 'OIDC Subject' && | ||
| !preg_match("/^([a-f0-9]{8}\-[a-f0-9]{4}\-[a-f0-9]{4}\-[a-f0-9]{4}\-[a-f0-9]{12})$/", $identifier) | ||
| !preg_match( | ||
| "/^([a-f0-9]{8}\-[a-f0-9]{4}\-[a-f0-9]{4}\-[a-f0-9]{4}\-[a-f0-9]{12})$/", | ||
| $identifier | ||
| ) | ||
| ) { | ||
| throw new \Exception("Invalid OIDC Subject"); | ||
| } |
There was a problem hiding this comment.
We have very similar checks on OIDC subject validity here and in /lib/Gocdb_Services/Site.php (and of course the checks differ slightly, though I believe this one is more correct.
Factoring this out, maybe pushing it (and X.509 validation as above) into the existing validation layer is a way forward.
@Sae126V, can you open an issue?
| @@ -94,41 +103,61 @@ public static function usage($message = '') | |||
| ( | |||
| "Usage: php ManageAPICredentials.php [--help | -h] [--dry-run] \\\ \n" . | |||
| " [--renewal | -r] \\\ \n" . | |||
There was a problem hiding this comment.
can we pass the property name as an option directly, rather than have a flag we specificy for one use case but not the other.
something like --property [ lastUseTime | lastRenewTime ] ?
There was a problem hiding this comment.
"inactive" and "renewals" as the properties.
There was a problem hiding this comment.
Specified two flags now one for lastUseTime and the other for lastRenewTime. instead of one.
| "the last $elapsedMonths months and will be deleted if this period of inactivity\n" . | ||
| "reaches $deletionThreshold months.\n\n"; | ||
| list($headers, $siteName) = $this->getHeaderContent($api, $fromEmail, $replyToEmail); | ||
| list($body, $userEmail) = $this->getInitialBodyContent($api); |
There was a problem hiding this comment.
With the body being split up like this, I find it hard to get a sense of what is being sent to the user.
Maybe a mapping between properties and body text would be easier alleviate this?
There was a problem hiding this comment.
Wrapped into single function that would provide fix to ease complexity.
Sae126V
force-pushed
the
GT-184-Extend-API-Credential-Management-to-handle-periodic-renewal
branch
from
bc37f58
to
6259cc5
Compare
| $params = array(); | ||
|
|
||
| if ($_REQUEST['isRenewalRequest']) { | ||
| $newValues['isRenewalRequest'] = $params['isRenewalRequest'] = true; |
There was a problem hiding this comment.
| $newValues['isRenewalRequest'] = $params['isRenewalRequest'] = true; | |
| $newValues['isRenewalRequest'] = true; | |
| $params['isRenewalRequest'] = true; |
if that is indeed the desired behaviour, it's clearer what's going on and doesn't have two assignments on one line.
There was a problem hiding this comment.
It is indented behaviour. Sure, I have removed assigning multiple variable at once.
Sae126V
force-pushed
the
GT-184-Extend-API-Credential-Management-to-handle-periodic-renewal
branch
from
8afb986
to
cd82c9e
Compare
|
@gregcorbett , This is ready for the functionality review. |
There was a problem hiding this comment.
Functionality looks good. I noticed that when emails were generated for both unrenewed and inactive API credentitals, I got:
> php resources/ManageAPICredentials/ManageUnusedAPICredentials.php --warning_threshold 9 --deletion_threshold 15 --renewals
...
The API credential associated with the following identifier
registered at site X has not been renewed for
the last 0 months and will be deleted if it reaches 15 months.
Where 0 should have been closer to 12, which is why the warning email was generated. Could you look into that?
|
Could you also add printing out the last renewed time to |
Sure, Greg. Added the support for last renewed time in 0d1ec9a |
Right. I see the flow of code was designed such that it calculates the month difference i.e. say, Sept to sept the month difference is zero and it ignored the year part. I have provided a fix in 0d1ec9a. |
|
Ready for the functionality review with the fix and suggestions @gregcorbett. |
Resolves
" #438 and #453 "