CTOR-2266 [apps::saas::apivideo::restapi] - new plugin

[garnier-quentin]

Community contributors

Description

New plugin to monitor Api Video (https://docs.api.video/reference/authentication-guide)

CTOR-2266

Type of change

• Patch fixing an issue (non-breaking change)
• New functionality (non-breaking change)
• Functionality enhancement or optimization (non-breaking change)
• Breaking change (patch or feature) that might cause side effects breaking part of the Software

How this pull request can be tested ?

$ perl centreon_plugins.pl --plugin=apps::saas::apivideo::restapi::plugin --mode=contents-usage --api-key='V2LoNXXXX' 
OK: Contents played: 155, watching time: 9h 9m 55s, concurrent users peak: 39 | 'contents.played.count'=155;;;0; 'contents.watch_time.seconds'=32995.531s;;;0; 'contents.users.concurrent.peak.count'=39;;;0;

Checklist

• I have followed the coding style guidelines provided by Centreon
• I have commented my code, especially hard-to-understand areas of the PR.
• I have rebased my development branch on the base branch (develop).
• I have provide data or shown output displaying the result of this code in the plugin area concerned.

Summary by Aikido

Security Issues: 0	🔍 Quality Issues: 1	Resolved Issues: 0

🚀 New Features

• Implemented new Api Video REST API plugin with contents-usage mode

⚡ Enhancements

• Added packaging metadata and dependencies for RPM and Debian packages

^{More info}

[aikido-pr-checks]

get_connection_info uses md5_hex over hostname:port:api_key. Avoid MD5 for values derived from secrets; use a stronger hash (e.g., SHA-256) or a secure identifier mechanism.

Details

✨ AI Reasoning
​The code computes an MD5 hash over the API key combined with host/port to create a connection identifier. This hash is derived from a secret (the API key) and is used in authentication-related cache logic (connection identification). Using MD5 for data derived from secrets poses a cryptographic risk: MD5 is broken and should not be used where secrets or authentication-related values are involved. A stronger hash (e.g., SHA-256) should be used for general hashing of secrets, or the secret should be stored/compared using a secure mechanism appropriate to the sensitivity and usage pattern.

🔧 How do I fix it?
Use modern alternatives: SHA-256/SHA-3 for general hashing, and bcrypt/scrypt/Argon2 (with salt and work factor) for passwords

_{Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info}