Aujourd'hui les liens transmis aux modérateurs et aux participants ne sont pas enregistrés en base mais calculés dynamiquement sur la base d'attributs portés par le meeting, et indirectement d'attributs portés par l'utilisateur.
|
def get_hash(meeting, role: Role, hash_from_string=False): |
|
"""Generate a hash for meeting access verification based on role.""" |
|
name = meeting.name or str(current_app.config["QUICK_MEETING_DEFAULT_NAME"]) |
|
s = f"{meeting.meetingID}|{meeting.attendeePW}|{name}|{role.name if hash_from_string else role}" |
|
return hashlib.sha1(s.encode("utf-8")).hexdigest() |
|
@property |
|
def meetingID(self): |
|
"""Return the unique BBB meeting identifier.""" |
|
if self.id is not None: |
|
fid = f"meeting-persistent-{self.id}" |
|
else: |
|
fid = f"meeting-vanish-{self.fake_id}" |
|
return "{}--{}".format(fid, self.owner.hash if self.owner else "") |
|
@property |
|
def hash(self): |
|
"""Generate SHA1 hash from user's email and application secret key.""" |
|
s = f"{self.email}|{secret_key()}" |
|
return hashlib.sha1(s.encode("utf-8")).hexdigest() |
Comme vu avec #386, ça nous pose des soucis dans les cas où l'on doit faire évoluer la construction du hash, puisqu'on doit maintenir une compatibilité ascendante avec les liens émis ad vitam. Dans le cas de cette PR en particulier, ça donne une situation fausse (où le reset d'un mot de passe participant peut casser un lien modérateur).
#254 projette de stocker le meetingID - utilisé dans le calcul des liens - en base de données. Ça aide puisque dès lors les liens ne seront plus dépendants des attributs utilisateur.
Je pense qu'on devrait faire la même chose pour les liens de meetings : on devrait stocker en base les liens plutôt que les calculer dynamiquement. Je propose que les liens soient générés avec des UUID plutôt que basés sur des attributs du meeting. Ça permettrait d'avoir notamment plusieurs liens valides en parallèle, de se détacher des contraintes de code rétrocompatible, de simplifier le code.
Aujourd'hui les liens transmis aux modérateurs et aux participants ne sont pas enregistrés en base mais calculés dynamiquement sur la base d'attributs portés par le meeting, et indirectement d'attributs portés par l'utilisateur.
b3desk/web/b3desk/join.py
Lines 14 to 18 in adfb203
b3desk/web/b3desk/models/meetings.py
Lines 170 to 177 in adfb203
b3desk/web/b3desk/models/users.py
Lines 104 to 108 in adfb203
Comme vu avec #386, ça nous pose des soucis dans les cas où l'on doit faire évoluer la construction du hash, puisqu'on doit maintenir une compatibilité ascendante avec les liens émis ad vitam. Dans le cas de cette PR en particulier, ça donne une situation fausse (où le reset d'un mot de passe participant peut casser un lien modérateur).
#254 projette de stocker le
meetingID- utilisé dans le calcul des liens - en base de données. Ça aide puisque dès lors les liens ne seront plus dépendants des attributs utilisateur.Je pense qu'on devrait faire la même chose pour les liens de meetings : on devrait stocker en base les liens plutôt que les calculer dynamiquement. Je propose que les liens soient générés avec des UUID plutôt que basés sur des attributs du meeting. Ça permettrait d'avoir notamment plusieurs liens valides en parallèle, de se détacher des contraintes de code rétrocompatible, de simplifier le code.