De tout temps ce site a été une catastrophe, c'en est presque devenu normal... u_u

Et encore, si il y'avait que ça...

Certaines personnes ont validé leur inscription, avec message de confirmation etc, pendant une période de gros stress serveur; ça a pas été enregistré correctement.
Heureusement c'était pas une période critique :/

En admettant que l'url est aléatoire et pas du type NOM_PRENOM, ça ne soulagerait pas un peu la charge de faire comme ça? (Bon, je suppose que c'était pas fait dans ce but, mais admettons), tout en étant relativement sécurisé (notez le relativement), et aussi car je ne sais pas à quoi correspond cette fiche pédagogique.

On ne soulage jamais la charge au péril de la sécurité !
Sous prétexte que ta voiture irait plus vite sans les freins et la direction assistée, tu les enlèverais ?

La sécurité c'est juste le bon compromis d'insécurité par rapport aux ressources consommées...

dans la mesure où on n'a pas la criticité des data c'est un débat stérile.

Je me souviens la fin de ma term, lorsque j'ai du m'y inscrire et m'en servir presque quotidiennement... depuis une connexion à 3-5 Ko/s à N'Djamena...

En attendant qu'une page charge, tu pouvais lire le journal!

Il y a entre autre (En plus des infos du style nom, date de naissance et des notes/commentaires) les numéros BEA et RNE, donc ceux qui permettent d'être identifié au niveau de la paperasse.
Bien que ce ne soit pas des informations capitales, je suis de base assez réticent au fait de savoir que des informations à mon sujet sont sur Internet.
Je reconnais donc que pour ça, c'est plus "un coup de tête" que j'ai posté par rapport à ça.
Désolé pour cette erreur d'objectivité.

D'un autre coté, je sait pas si c'est vraiment la vérification des données d'authentification qui consomment le plus sur le site...
Surtout que je ne pense pas que tout le monde y aille aux heures de pointes un tel jour dans le but de regarder cette fiche (Personnellement, je ne l'ai fait que parce que j'ai appris l'existence de la fiche le jour même.)

ok, donc des info perso, en effet, ça devrais pas être accessible sans identification.
(pas une grosse protection à mettre dessus, mais que ça puissent pas se balader sans contrôle)

et tu a pas à t'excuser pour l'objectivité, c'est juste que pour juger d'une "faille" il faut la mettre en relation avec ce qu'elle permet (si c'est changer la couleur du background avec un cookie c'est pas la même chose qu'une backdoor full root)

Non, c'est simplement que le serveur reçoit en moins de quatre heures environ 600000 consultations, ce qui fait quelques gibioctets à balancer en HTTP. Et surtout, étant donné que la plupart des élèves tentent de valider leur voeu ou de dire qu'ils attendront la prochaine phase, ça fait aussi quelques millions d'entrées dans une base de donnée immense, complexe et probablement mal foutue à modifier ou supprimer. Voilà pourquoi le serveur ne répondait même pas aux pings !
Et dire que jeudi, on va avoir droit à la même horreur...

Au fait, elle sert à quoi, cette fiche ?

On pourrait avoir un exemple de l'url? Tu la changes hein :p

Car comme le dit D., si on a une url suffisament longue et aléatoire, il n'y a aucun problème de sécurité vu que la probabilité de la trouver est inférieur à la probabilité de trouver un couple identifiant / mot de passe :)

Tout les sites qui ont de la charge le font pour les documents statiques, exemple: facebook pour les photos.

Ca me semble bizarre... Dans le sens: Je ne vois pas vraiment comment ils auraient pu faire une erreur aussi grosse.

Par contre, il est possible qu'il ne soit pas visible directement, vu qu'ils ont peut être des bdd slave pour la lecture, qui n'ont pas encore été actualisées.

Plaignez vous tiens... de mon temps on passait par le minitel :)

Non, c'est réel, c'est juste que le serveur est à nouveau down au moment ou le type appuye sur le bouton.
Très énervant pour ces personnes, à mon avis.

Pour info, un serveur peut être configuré pour ne jamais répondre au ping, ce n'est donc pas un moyen fiable de se renseigner sur son état - sauf bien sûr si l'on sait qu'en temps normal ledit serveur répond au ping.

Mais si le serveur est down, il n'y aurait pas eu de message de confirmation comme l'indique Kom.ic

Et selon toute logique, le message arrive après le commit. Ils fonctionnent peut être différement, mais ça m'étonnerait :)

Ah, j'avais pas vu le "avec message de confirmation".
Je vérifierai ça à la prochaine étape si j'y pense (demain, c'est bien ça?)

Justement, pour l'avoir aussi à une époque utilisé: Le réseau Minitel fonctionnait, lui.

Le site postbac subit des attaques de déni de service depuis sa mise en production, d'où les lenteurs...

A la question potentielle "pourquoi ne rien faire contre ?" : parce que la lutte contre les DDOS suppose de perdre quelques connexions légitimes, et dans un contexte de planning serré (les inscriptions), ce serait préjudiciable à de nombreux étudiants... Le choix a est été fait d'être lent pour tout le monde à certains moments (quand le DDOS a lieu) plutôt que de perdre des inscriptions à ce moment là.

Pour la l'histoire de la fiche, je vais transmettre votre information. Mais vu que les éléments techniques ne sont pas suffisants (on est dans un site de blagues, pas un helpdesk ;-) ), je crains qu'aucune réponse ne puisse être apportée.

Bonne journée.

Normalement, ça me met « Packet filtered ». Le 13 juin, j'avais pas de réponse.

Des DDOS ? D'où ? De France ?

De partout.

Mais suivant les cas cela a été un DDOS UDP (les adresses IP attaquantes sont usurpées), ou un DDOS de type "LOIC"... (adresses IP non usurpées mais souvent provenant de machines "zombies" et saturant de requêtes HTTP le serveur).