Arrêtons les bêtises

Vive Irone!! Il établit la vérité et on voit ça ne plaît pas!

y'a aucune faille de sécurité tant que c'est pas de la data sensible, faut arrêter... ils ont cloudflare qui s'occupe de bloquer en cas de problème... oui normalement tu mets une pagination et c'est évident pour des raisons d'optimisation, mais on est sur de la base de données relationnelle, c'est conçu pour traiter un grand nombre de données même avec des dizaines de jointures, si bien indéxé, donc je vois pas pourquoi vous faites peur en parlant de "FAILLE" alors que ca n'en est pas une... Et puis pk se plaindre de compromettre la sécurité dans un poste PUBLIQUE, bref message inutile non pertinent, au pire dm le et demande lui pk il a retiré pagination 

Bonjour,

Bha pourquoi pour certaines personnes, ca pose un problème qu'il ai les accès (Irone) ?

 L'api est un projet indépendant d'HabboCity qui est un outil accessibles aux développeurs et membres des organisations qui en justifient la demande.

Y'a quoi comme risque en faite ? J'aimerais bien qu'on m'explique ? J'ai confiance en Irone et j'ai volontairement laissé les accès pour qu'il puisse s'il le veux, ajouter un jour des fonctionnalités (dans la mesure du raisonnable) sur l'api ! Bien entendu avant que ce soit envoyé sur le serveur, de City je verifie le code et j'attends qu'on me justifie le commit, c'est pas parce qu'un développeur sur le GitHub mets un code malsain et pas legitime que je vais forcément l'autorisé ou que le code va être injecté dans le serveur par le développeur. C'est moi qui PUSH le code à jour vers le serveur, moi et personne d'autre.

@Dylanos et ce genre de chose devrait se gérer en interne de toute manière.. Pour moi c'est juste pour faire du drama pour rien en affolant les 4-5 pixels qui vont s'enflamer encore, le principe d'un API c'est de faire la liaison entre la base de donnée et les service (en gros avoir une couche de securité) ou mapper des données brutes en objets documentés, anyway les accès sont de toute manière sécurisés par des permissions SQL side donc je comprends même pas l'intéret du post

@gogolafarce Cloudflare sert à rien dans ce cas de figure, ça peut servir à faire du rate limiting mais dans ce contexte précis un joueur peut construire une requête beaucoup trop lourde qui entraînerait un dénis de service...

Pour revenir sur ce que disait Dylanos, je n'ai plus d'attribution officielle sur City depuis plus d'une année, donc oui il était anormale que j'ai encore accès au code source. Pour le reste, j'ai été amené à intervenir régulièrement sur des problématiques techniques, à mon bon vouloir, sans attribution, ce qui nécessitait l'accès au code source. Il s'agissait d'un contrat de confiance, qui n'a jamais été rompu 😉

À chacun son appréciation de cette situation !

@Irone ça dépends de quelle route tu parles, s'il y a des filtres obligatoires par exemple nom d'utilisateur, tu vas difficilement faire un deni de service, si tu peux choper toute la bdd en choisissant un nombre de page affolant c'est une autre histoire, je suppose qu'il y a des filtres et des indexes mis en place et qu'il select pas sur l'intégralité de la data, menfin surtout sur une API ça me paraît très étonnant, surtout sur une route publique type /api/users (mais qui n'a pas vraiment de sens dans le contexte de city puisqu'on ne charge pas de liste d'utilisateurs pour l'afficher publiquement sur le site à ma connaissance, donc je suppose que c'est du /api/users/id ou /api/users?q= au minimum. Et Dylanos a expliqué qu'il avait le dernier mot sur le push du code en prod, donc on s'en fou que t'ai le code de l'API ou pas s'il n'y a pas de data sensible (si bien fait t'es pas sensé en avoir)

rien compris mais je suis d'accord avec @Irone

Je me permet car je te croise rarement et te voilà en ligne @dylanos alors j'aimerai savoir où ça en est concernant le dossier des appartements officiels supprimés par ?  

On (pour ne pas dire tu) nous as dis que les appartements seraient restitués grâce à un back-up. Aux dernières nouvelles tu avais annoncé "back-up demain soir" ... 
Nous voilà 3 semaines plus tard, et toujours rien.....
On nous a parlé d'une compensation, toujours rien non plus.

Suis-je censé annoncer aux équipes de l'organisation que, leur travail a été définitivement supprimé, et ce gratuitement par un joueur qui, encore aujourd'hui continue de contourner son BL, menace les joueurs de doxx, de viol, et j'en passe.

Comment les membres d'organisation et les staffs pourraient-ils rester motivés à créer du contenu et divertir la communauté, quand leur travail est si peu considére?...
Simplement dire les choses, si ça n'est pas faisable de restituer les appartements, dites-le clairement et ne nous laissez pas mariner de la sorte s'il vous plaît

omg !!!! 

Salius le pistonné parceque c'était un léche-bottes de modo mdrrrr

@frere quels modos ?

depuis quand les modos ont une influence sur le choix de recrutement d'un développeur ?

C'est marrant de voir autant de drama pour une API qui permet seulement de récupérer un nombre très limité d'informations. 😂
J'suis totalement d'accord avec Irone par contre sur le fait que la base de donnée n'est pas assez optimisée (le fléaut des rétros d'ailleurs) pour passer de la limite de 15 groupes à une infinité.
Sachant que normalement les groupes sur Habbo sont limités à 100, ça reste une requête SQL qui recherche sur une table, parmis sûrement des centaines de milliers d'entrées pour afficher les 100 groupes de X, c'est pas génial.

Par contre, ce qu'il serait intéressant de mettre en place pour cette API serait des limites tout simplement avec un système de cache afin de limiter les requêtes SQL qui demandent de nombreuses ressources à la base de donnée.
Perso pour mon API (sur un projet perso), j'ai mis en place des RateLimits ainsi qu'un nombre limité de requêtes par token par exemple pour l'endpoint "/v1/status", on est limité à 600 requêtes sur une fenêtre de 5 minutes par token.
De plus certaines données sont gardées en cache, par exemple pour l'endpoint "/v2/quest/{id}", les données ne changent pas "normalement", donc lorsque la donnée est appelée, je la stock dans un fichier JSON interne, donc mon code vérifie déjà si l'entrée existe dans le fichier, si oui, elle ne fait aucune requête SQL, si non, elle fait une requête et l'ajoute au fichier.
De façon hebdomadaire, l'API vérifie si une donnée statique comme les quêtes a changé, si oui, elle met à jour le fichier en récupérant uniquement les données stockées dans le fichier JSON.

Après j'imagine que l'API d'HabboCity n'est pas comparable à la mienne étant donner que y a pas autant de données dans la base de donnée, mais ça marche plutôt bien et c'est une assez bonne technique.
L'avantage d'HabboCity est qu'à chaque connexion/déconnexion des joueurs, on peut mettre à jour facilement ce type de fichier, si le joueur est déjà entré, c'est qu'il a déjà été appelé, donc on met à jour ses stats lors qu'il se déconnecte.
Même si en général, on aime avoir des statistiques en temps réel, sécuriser et protéger une API permet aussi d'appliquer le même principe à une base de donnée friable.

@Equitable SQL est conçu et optimisé pour traiter des millions de données avec des dizaines de jointures, 100 lectures, on s'en tape le cul royalement si je peux me permettre, concernant ta mise en cache, utilise redis qui est bien mieux adapté, mais dans ton cas c'est inutile de mettre en cache surtout pour gratter si peu. surtout que tu fais des lectures/écritures à plus haut niveau pour optimiser ce que des mathématiciens avec vingt ans d'experience ont mis en place très bas niveau et conçu pour du gros volume

la limite de 100 ici n'existe pas contrairement à Habbo, d'où le fait que je n'ai pas mis de limite à 100.

comme je l'ai annoncé sur le flux, l'API est le prochain gros projet en terme de majs pour augmenter son utilité