You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now if an appsec component gets a valid response from the LAPI and then ultimately the LAPI goes down we have a auth cache which is fine if you configure it for the "expected" downtime, however, most of the time you dont know how long the downtime will be.
/kind enhancement
Why is this needed?
A potential improvement could be to check if the api key was ever in the cache and presume it is safe until we get a response from LAPI and then ultimately we can invalidate the cache if the key is now invalid to allow better HA
The text was updated successfully, but these errors were encountered:
Check Releases to make sure your agent is on the latest version.
Details
I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.
@LaurenceJJones: There are no 'kind' label on this issue. You need a 'kind' label to start the triage process.
/kind feature
/kind enhancement
/kind refactoring
/kind bug
/kind packaging
Details
I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.
What would you like to be added?
Right now if an appsec component gets a valid response from the LAPI and then ultimately the LAPI goes down we have a auth cache which is fine if you configure it for the "expected" downtime, however, most of the time you dont know how long the downtime will be.
/kind enhancement
Why is this needed?
A potential improvement could be to check if the api key was ever in the cache and presume it is safe until we get a response from LAPI and then ultimately we can invalidate the cache if the key is now invalid to allow better HA
The text was updated successfully, but these errors were encountered: