It was suggested to implement some sort of authorization to prevent some users from impersonating the others and creating certificates in their names.
In the original version, there were a request-approval system but I remove it in v2 for the following reasons:
it was hard for the maintainer to review all requests
it was hard to validate the request (if someone told me that he is a lead at GDSC BlaBlaBla, I can't verify it sometimes)
This will prevent the future leads from using the website
So with that being said, another system can be implemented that should fix all these problems. The idea is that all leads have access to to the global slack workspace Google Developer Student Clubs . So if I created a password and shared it there, only the leads will be able to login and read the message.
It's the lead's responsibility to protect the password and not leak it. But if this happened, The message can be edited with the new passwords.
To implement such system, the login component needs to be abstracted and updated
It was suggested to implement some sort of authorization to prevent some users from impersonating the others and creating certificates in their names.
In the original version, there were a request-approval system but I remove it in v2 for the following reasons:
So with that being said, another system can be implemented that should fix all these problems. The idea is that all leads have access to to the global slack workspace
Google Developer Student Clubs. So if I created a password and shared it there, only the leads will be able to login and read the message.It's the lead's responsibility to protect the password and not leak it. But if this happened, The message can be edited with the new passwords.
To implement such system, the
logincomponent needs to be abstracted and updated