Add certificate access protection

[Bavarianspirit]

Any user who is logged in can explore all other users certificates simply by
altering the parameter id in the url.

Given the user has id 4, the url reads:
https://myhostname/certificates/index.php?id=4

Changing the id to any other valid user id will show another users
certificate, if it exists:
https://myhostname/certificates/index.php?id=5

This is a huge privacy issue as it may reveal names and other personal user
data that is included in the other users certificates.
As a workaround I suggest to add the following check to
/certificates/index.php somewhere below the lines

$certificate = new Certificate($certificateId, $userId);
$certificateData = $certificate->get($certificateId);
if (empty($certificateData)) {
api_not_allowed(false,
Display::return_message(get_lang('NoCertificateAvailable'), 'warning'));
}

// BEGIN WORKAROUND
if ( api_get_user_id() != $certificate->user_id ) {
    api_not_allowed(true);
    }
// END WORKAROUND

Beeing a workaround, this will even prevent admins or course admins from
viewing students certificates.

[ywarnier]

This is correct. We assume (for now) that certificates are something you're proud to show off to others and allow other portal users to scan them. There is an effort for certificates and skills to be identified by an SHA hash rather than a sequential numerical ID in Chamilo 2.0.

There is an option (enabled by default) to prevent anonymous users to access certificates, but it doesn't block access from other registered users.

[Bavarianspirit]

In EU and other coutries the DSGVO does not allow this. Everything that can identify an user by one self or by other persons by any informations is denied. So this Portal is not usable where the DSGVO is a law.

The only way is, that the user accept this on registration site with an active ok. And a double opt in for security! If he does not, this portal is not usable and this is not allowed by our law.

By the way, make your next release it's ok but in Germany (and i think EU also) this software release and older are not allowed!

[ywarnier]

@Bavarianspirit we are based in Europe. This is just an option. Feel free not to generate certificates to avoid the issue, or to include this as a requirement in your DSGVO/GDPR terms. There is no such thing as "not allowed" in the GDPR as long as you inform the users and allow them to decide they don't want to.
By the way, printing names in certificates for other users on the same platform is the same as printing names in a students list in a hallway in a physical institution.

[ywarnier]

This feature request implies creating a new table with the list of certificates and their properties (when it was generated, for whom, linked to which resource (gradebook+course+session, whether the user wants it to be public or not, the old numeric ID and a new SHA string (not only based on this ID) to use in the URL to make it difficult to scan through).

[ywarnier]

State of the trade in 2025 : the gradebook_certificate table already has a user_id and a path_certificate that is generated from a (random?) hash.
We're only missing an option for the user to say whether (s)he wants to publish it or not.

This would require (for now) an option as "gradebook_certificate.publish" (bool) which would be 0/false by default.

@christianbeeznest could you add that field to the 1.11 to 2.0 migration and to the gradebook_certificate entity?

Then we will have to fix all the certificates stuff because currently, the link points to the internal ID (instead of the hash) and is not working.

[christianbeeznest]

Hi @ywarnier ,

I've added the publish field (boolean, default false) to the gradebook_certificate entity and included it in the 1.11 to 2.0 migration — ready for alpha 3.

To complete the fix, could you please point me to a specific example (e.g. a page or component) where the certificate link is still using the internal ID instead of the path_certificate hash? That will help me identify the exact part that still needs to be updated.

Thanks!