Reprise du message précédent :
Bah nan c'est la technique qu'il a adoptée le adsense dessus

 
Nah mais il me semble savoir que Joce ne vit pas de MD.net...

Autre idée vu que celle des id de pages mouvants n'a pas plu ...
 
Quand vous supprimez un message d'un topic, (réellement ou en marquant un champ "supprimé" ), vous ajoutez à une table "deletedmess" séparée de la forme :

 
la paire idtopic/idmessage du message supprimé.
le cout est évidemment constant quelle que soit l'ancienneté du message ou la taille du topic.
 
Ensuite, quand on veut afficher la page X du topic, avec Y posts par page (je zappe l'affichage du message de la page d'avant comme joce pour simplifier...), je me plante ptêtre dans les détails de la syntaxe SQL mais l'idée est la :
 
SELECT * FROM "tabledesmessage" WHERE idmessage BETWEEN
(X*Y+ (SELECT COUNT(idmessage) FROM "deletedmess" WHERE idmessage<=X*Y AND idtopic=id))
AND ((X+1)*Y+ (SELECT COUNT(idmessage) FROM "deletedmess" WHERE idmessage<=(X+1)*Y AND idtopic=id))
 
Une requète avec 2 sous-requètes, surement améliorable, mais les 3 requètes sont simples, rapides, et facilement indexables. de plus on peut escompter une taille assez faible pour la table "deletedmess".
La encore, la lecture se fait en temps constant, et on a même pas été obligé de pourrir la table avec un champ supplémentaire, de splitter, ou d'avoir des marqueurs.
 
En fait, si on a un champ qui marque les messages supprimés et qu'on les supprime pas vraiment,  au lieu d'avoir une table "deletedmess", on peut faire les COUNT directement sur la "tabledesmessages", je ne sais pas ce qui serait le plus rapide, c'est à tester.
 
SELECT * FROM "tabledesmessage" WHERE idmessage BETWEEN
(X*Y+ (SELECT COUNT(idmessage) FROM "tabledesmessages" WHERE idmessage<=X*Y AND idtopic=id AND deleted=1))
AND ((X+1)*Y+ (SELECT COUNT(idmessage) FROM "tabledesmessages" WHERE idmessage<=(X+1)*Y AND idtopic=id AND deleted=1))

Pas mal et c'est vrai que les requêtes sont légères
 
Maintenant ça ne marchera que pour un forum vierge car les trous dans les ID deletés avant la mise en place de ton système ne sont pas dans la table deletedmess OU ALORS il faut recalculer tous les ID intra-topic avant de lancer cette méthode histoire de boucher tous les trous.  
 
T'es quand même obligé d'y ajouter des ID intra-topic pour ton BETWEEN donc pkoi tu dis "et on a même pas été obligé de pourrir la table avec un champ supplémentaire, de splitter, ou d'avoir des marqueurs." ?
 
EDIT : Et histoire d'alléger la table qui contient le couple IDmessage/IDtopic, tu peux la vider tous les 6 mois et recalculer tous les ID intra-topics qd y a personne ou a l'occasion d'une maintenance, ça simplifiera encore +.

Si on a un champ qui marque les messages supprimés, on peut employer la seconde requète, et donc pas de table deletedmess. Sinon oui, il faut lister les trous

Dans mon idée on a d'emblée un id intratopic, mais c'est vrai qu'on peut avoir un forum sans, auquel cas il faut effectivement le rajouter.

Peut-être, mais je doute qu'il y ait assez de messages supprimés pour que cela soit utile.

mais j'ai l'impression que invision board en vivent
 

bah au moins c'est bien ils vivent sans scrupules pour les gens qui achètent ça ^^

Et y en a beaucoup, Joce y doit être jaloux

T'inquiète il commence à se rattraper niveau failles de sécu, d'ici à ce qu'on en trouve d'autres

Hum... la popularitée d'un forum serait donc lié à son nombre d'alerte de faille de sécu ?

nan, mais en général plus un forum est populaire, plus les hackers s'y intéressent et plus il a de failles de sécu

ca serait plutot le contraire
 
le nombre de faille de sécu lié a la popularité du forum.
 
+ il est populaire, + de faille sont détécté sachant qu'avec un programme aussi complexe qu'un forum, il est difficile, voir impossible, d'avoir 0 failles.
 

Voilà

C'est pour ça que pendant bien longtemps, Apache avait moins d'alertes de sécurité que IIS malgré une plus grande part de marché.

y'a des exceptions comme le montre ton message...

Euh... oui mais non. Faut voir comment sont faits les stats et à qui rapporte le hack. D'une part, les stats des  webservers se basent sur les noms de domaines, ce qui profite à Apache vu que l'immense majorité des mutus tourne sous Apache. D'autre part, ce n'est pas intéressant de viser des petit sites alors que d'autres sites commerciaux tournent sur IIS, WebSphere ou Zeus.

Faut arrèter avec ça. Avec un minimum de part de marché, c'est que la qualité du code qui influe sur le nombre d'attaques. Apache n'a PAS une petite part de marché et il y a PLEIN de sites serieux qui tournent sous Apache. Les anciennes versions d'IIS sont juste des catastrophes au niveau de la sécurité ( ils se sont bien améliorés depuis ).
 
Si tu savais. Ca ne veux pas dire grand chose, les banques ne sont pas spécialement connues pour avoir un bon niveau en sécurité sur Internet.

Non, ce que j'ai dis c'est que malgré une très grande part de marché pour Apache et pour IIS, c'est ce dernier qui était le plus attaqué et de loin et il était bien connu pour être mauvais au niveau de la sécurité ! Comme quoi le fait d'être le plus attaqué n'est pas lié au fait d'être le plus populaire.
 
Et puis, leur façon de corriger des failles de sécurité était affligeante quand même. Quand ils avaient la faille qui permetait de faire ../../ pour accéder à C:\Windows\Cmd.exe?"mettre ici commande arbitraire", une fois corrigé il suffisait de remplacer les slash par l'équivalent en %. Il avaient juste mis une grosse regexp pour interdire les URL avec ../ dedans

je pense que ça dépend largement de la visibilité aussi.

moi je voulais jsute dire que si apache etait moins connu, il y aurait moins de faille d'apache dévoilé ou trouvé
 
Donc, plus le logiciel est connu, plus la "communauté" de hacker augmente envers ce logiciel.
 

Oui, ça c'est bien vrai. Il faut juste éviter de tomber dans l'excès et d'en conclure que le plus hacké l'est parce qu'il est le plus populaire

L'exception qui confirme la règle : PHPBB  

PHPBB c'est surtout parce qu'il est le plus mal codé

 
Ce genre de bug se controlle tres bien avec un WAF, mais bon ça ne fait pas tout, si un site est codé avec les pieds un firewall ne fera pas tout...

C'était un bug de IIS ça, c'est le serveur web qui était codé avec les pieds. Et puis, c'est pas à l'admin de palier aux bugs du server web en mettant des règles de firewall partout aussi.

Oui mais quand il y a une faille du serveur, tu es bien contant de l'avoir ton firewall

Ptite question comme ça, il existe des versions serveur de MACOS ?

Oui

 
ça depend le firewall d'un coté, un firewall qui analyse la couche reseau, ou un firewall qui s'occupe du flux web, mais c'est vrais qu'ils ont impressionant par leur possibilité

Faut bien penser aussi qu'un firewall qui fait des analyses complètes, ça bouffe du CPU et ça risque de saturer la machine s'il y a trop de paquets réseau qui passent.

suffit d'emprunter les serveurs que clubic utilise pour son forum

Le serveur est déjà saturé à cause du forum justement

 
Et en bonus, il peut avoir une (tres chere) carte d'accélération SSL

Salut,
Vous avez fait comment pour eviter le limit dans la liste des sujets?

remontes de ~10pages (y'a des infos 2 pages avant aussi)

Cyrius-c > Deux solutions : où tu ne l'évite pas, ou bien tu notes dans une colone en quelle position est le sujet dans la liste (quand un sujet recoit un message, tu mets son indice à 0 puis tu augmentes de 1 tous ceux qui étaient en dessous de lui au départ lui y compris vu qu'il se retrouve avec le numéro 0 à ce moment là.
Comme ça, de 1 à 30 t'as les 30 premiers messages, de 31 à 60 les 30 suivant et etc.

Merci.
Je fais la première solution déjà
C'est assez lourd quand meme car faut updater tous les sujets a chaque nouvelle réponse.

non faut uploader tous ceux qui ont eu une réponse après le sujet auquel tu réponds, et vu qu'en général on répond aux sujets les plus récents, c'est très rapide.

Ah effectivement, c'est pas comme ca que je faisais alors
Merci pour le conseil

Et lors de la création d'un topic ? Tu fais comment sans tout décaler ?  

Rainbow_Ef reet > Tu l'insére en zéro et t'augmente tout le monde de 1. (bon, ok, c'est le point noir de la méthode)