Suivi — Comptes utilisateurs Slug purement numérique pour un compte utilisateur et effet sur le routage

#2066 Posté par Benoît Sibaud (site web personnel) le 06 mai 2023 à 11:10. État de l’entrée : ouverte. Licence CC By‑SA.

Étiquettes : aucune

mai

2023

Il y a un comportement un peu imprévu sur les slugs des comptes utilisateurs. Normalement on peut aller sur /users/<id> et se faire rediriger vers /users/<slug> de l'utilisateur en question. (on peut discuter si c'est souhaitable ou pas, mais c'est le cas actuellement en tout cas)

Mais il y a un souci quand un compte a un login purement numérique (1234567) ou dont le slug généré sera purement numérique (comme avec +228 ou 白白 ou ктйн). Ce slug généré va masqué celui du bon utilisateur associé à l'id égal au slug, et on est renvoyé vers un autre compte ayant un id différent.

Pas bien sûr de la conséquence, pas bien sûr qu'il faille empêcher de générer un slug purement numérique en amont…

En tout cas, actuellement, il y a 240 occurrences via

SELECT accounts.login, users.id, users.cached_slug, role, slug FROM friendly_id_slugs LEFT JOIN users ON users.id=sluggable_id LEFT JOIN accounts ON accounts.user_id=users.id WHERE sluggable_type='User' AND slug RLIKE '^[0-9]+$' AND sluggable_id <> slug;

dont 95 qui n'ont déjà plus de comptes (pas d'entrée dans accounts, uniquement dans users), et 44 qui ont des comptes fermés… reste à voir s'ils ont vraiment des contenus/commentaires associés sinon on peut changer les slugs plus facilement/discrètement. Attendons le nettoyage post 28 juin pour ça en tout cas, parce que ça va aider grandement.

Faut-il mettre à jour la gem qui gère la production du slug et/OU le routage suivant le slug ? Changer la règle de production du slug (même si on change la production de slug pour ajouter XXX123 quand on ouvre le compte id 123, on aura toujours une collision si on ouvre un compte login XXX123 de toute façon…) ?

# Comment friendly_id semble fonctionner

Posté par Adrien Dorsaz (site web personnel, Mastodon) le 06 mai 2023 à 22:49. Évalué à 3 (+0/-0).
Faut-il mettre à jour la gem qui gère la production du slug et/OU le routage suivant le slug ? Changer la règle de production du slug (même si on change la production de slug pour ajouter XXX123 quand on ouvre le compte id 123, on aura toujours une collision si on ouvre un compte login XXX123 de toute façon…) ?

Alors la documentation de friendly_id stipule clairement qu'elle ne gère que la partie base de donnée. Le routage est géré manuellement.

Avec LinuxFr, par exemple pour le controlleur de user, c'est géré comme ça:
```
# encoding: utf-8
class UsersController < ApplicationController
  before_action :find_user

  def show
    path = user_path(id: @user, format: params[:format])
    redirect_to path, status: 301 and return if request.path != path
    find_nodes([News, Diary])
    respond_to do |wants|
      wants.html
      wants.atom
    end
  end

[...]

protected

  def find_user
    @user = User.find(params[:id])
    raise ActiveRecord::RecordNotFound.new unless @user
    @contents = @user.nodes.visible.by_date.limit(20)
  end

[...]

end
```
Depuis le paramètre id qui vient du path de l'url (/users/:id), on cherche l'utilisateur qui correspond avec User.find (id peut être soit un slug, soit un l'identifiant numérique de l'utilisateur).

Si le path de l'utilisateur trouvé ne correspond pas au path courant, alors on redirige. Je ne connais pas assez Ruby On Rails pour savoir comment est géré la fonction user_path, mais j’admets qu'elle fonctionne correctement.

La gem friendly_id modifie la fonction find (parce que l'addon :finders est activé dans friendly_id.rb):

FriendlyId offers enhanced finders which will search for your record by friendly id, and fall back to the numeric id if necessary.

C'est pour ça que l'utilisateur avec un slug numérique aura la priorité sur l'utilisateur qui a l'identifiant qui correspond au slug.
Répondre
- [^] # Est-ce voulu ?
  
  Posté par Adrien Dorsaz (site web personnel, Mastodon) le 06 mai 2023 à 23:02. Évalué à 3 (+0/-0).
  
  Si je reprends la conversation que l'on avait eu au sujet de l'attaque par homoglyphe, l'intention est bien de cacher les identifiants numériques pour ne rendre visible que les slugs:
  
  Oui on a fait disparaître la plupart des identifiants des 'accounts' et des 'users', ce n'est pas pour les remettre maintenant.
  
  D'ailleurs la redirection semble bien faire ça: si tu essaies de trouver un utilisateur par un identifiant numérique, alors tu es redirigé vers son url avec slug.
  
  Donc, je dirai que ce comportement est voulu puisque l'on ne veut pas spécialement rendre publique les ids de la base de donnée.
  
  Pour aller (presque¹ ) au bout de cette idée de cacher les ids de base de donnée, on pourrait remplacer la redirection par une erreur 404 et n'autoriser l'accès que via les slugs.
  
  On risque d'être un site moins cool, puisque ça va casser les vielles urls comme https://linuxfr.org/users/4, mais bon ça fait depuis 2011 que linuxfr.org répond avec des redirections permanentes (HTTP 301) vers les slugs :)
  
  1: presque, parce que les identifiants sont visibles lors de l'upload de l'avatar et de la feuille CSS si on connaît l'algorithme de création des dossiers.
  
  Répondre
  - [^] # Re: Est-ce voulu ?
    
    Posté par nud le 25 mai 2023 à 09:35. Évalué à 2 (+0/-0). Dernière modification le 25 mai 2023 à 09:35.
    
    Ou alors tu introduis une url linuxfr.org/@slug ou linuxfr.org/~slug (qui ne gère que les slugs) et tu fais une 304 depuis /user/slug (qui est ambigue). Les @ sont à la mode :-)
    
    Répondre