Feature/persist installed certificate hashes #284
Conversation
elliot-sabitov
commented
Oct 19, 2024
•
elliot-sabitov
commented
- feat: adjusting implementation such that a GetInstalledCertificateIds message is triggered after a successful InstallCertificate response is received from the charger. The GetInstalledCertificateIds body that is received from the charger will now also be persisted in the new InstalledCertificate table to keep track of the certificates that are installed on the charger allowing easy access to issuerName and issuerKey hash values. Ensuring that a successful DeleteCertificates response from the charger also triggers the GetInstalledCertificateIds to ensure that our Installed Certificates table data is refreshed.
- feat: ensuring that we persist issuerKey of the certs that are generated in certificateChain request.
…InstalledCertificateIds message is triggered after a successful InstallCertificate response is received from the charger
…ificateIds handler and adjusting delete handler to re-trigger getInstalledCertificateIds so that we can keep latest state in sync with DB
01_Data/src/layers/sequelize/model/Certificate/InstalledCertificate.ts
Outdated
Show resolved
Hide resolved
01_Data/src/layers/sequelize/model/Certificate/InstalledCertificate.ts
Outdated
Show resolved
Hide resolved
| if (certificateHashDataList && certificateHashDataList.length > 0) { | ||
| // delete previous hashes for station | ||
| try { | ||
| await this._installedCertificateRepository.deleteAllByQuery({ |
There was a problem hiding this comment.
We cannot always delete all certificates in a station because user can send the GetInstalledCertificateIdsRequest to get only one or few GetCertificateIdUseEnumTypes, e.g., V2GRootCertificate. How about finding all certificate types inside the certificateHashDataList at first and only delete these types of certificates?
There was a problem hiding this comment.
for now adjusting module to not automatically trigger GetInstalledCertificateIds, and when GetInstalledCertificateIds payload comes in from the charger, deleting only installed certificate records with matching certificate types.
| message.context.stationId, | ||
| ); | ||
| try { | ||
| await this._installedCertificateRepository.deleteAllByQuery( |
There was a problem hiding this comment.
Here is the same reason as in the previous comment, so we cannot simply delete all installed certificates in db.
Another idea I have is that we can add a new optional field certificateType in this CallMessage table. Whenever GetInstalledCertificateIdsRequest is called, we stores the correlation id and certificateTypes in this CallMessage table. Then when getting response, we can retrieve the CallMessage entity to know what types of certificate are requested. An example is here:
There was a problem hiding this comment.
for now adjusting module to not automatically trigger GetInstalledCertificateIds, and when GetInstalledCertificateIds payload comes in from the charger, deleting only installed certificate records with matching certificate types.
…ashDataType and HashAlgorithmEnumType to better match spec, and adjusting module to not automatically trigger GetInstalledCertificateIds, and when GetInstalledCertificateIds payload comes in from the charger, deleting only installed certificate records with matching certificate types.
…shes * rc-1.5.0: fix: adjusting concurrent check to only happen after authorizations have been applied to ensure that eventType = Updated does not result in unknown status feat: created LatestStatusNotification model and adjusting logic such that when a new status notification is added for a station we also update the LatestStatusNotifications table ensuring that the latest record for the evse/connector is saved in the DB updating in order to work with operator ui # Conflicts: # 01_Data/src/interfaces/repositories.ts
For the OCA Certification, it looks like the get cert ids message will be triggered manually. In order to simplify the setup for now, we decided to take this out |
