Il me semble que les websockets, c'est quand même fait pour faire du connecté… Bref, je ne suis pas dans la technique bas niveau, mes propos se veulent être sur du design très général.
Peut être qu'une application web simple et un montage fuse par exemple suffise à basculer les données finale sous la bonne identité et résolve en partie le soucis ?
Sinon, le login pour l'hébergement ne te sers qu'a mettre à jour ton application, il ne sers à rien pour l'application elle-même et ne se retrouve pas sur le serveur. Je ne vois donc pas pourquoi cela reviendrait au même ? Pour moi, cela n'a rien à voir avec ce que je proposait.
Exemple : si le code php login.php n'avait accès à la base de données qu'en lecture, on éviterait toute écriture sur la BDB tant que la personne n'est pas identifiée. Ensuite, sur les autres pages php, si une personne attaque, elle a un identifiant donc peut être tracée et surtout ce type d'attaque relève du règlement intérieur de l'établissement… Bref, je ne vois que des avantages à cloisonner un peu mieux les requêtes SQL afin des les rendre plus robuste aux bogues !
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche ownCloud 4 est sorti. Évalué à 2.
Ai je dis que c'était tout pareil ?
Il me semble que les websockets, c'est quand même fait pour faire du connecté… Bref, je ne suis pas dans la technique bas niveau, mes propos se veulent être sur du design très général.
Peut être qu'une application web simple et un montage fuse par exemple suffise à basculer les données finale sous la bonne identité et résolve en partie le soucis ?
Sinon, le login pour l'hébergement ne te sers qu'a mettre à jour ton application, il ne sers à rien pour l'application elle-même et ne se retrouve pas sur le serveur. Je ne vois donc pas pourquoi cela reviendrait au même ? Pour moi, cela n'a rien à voir avec ce que je proposait.
Exemple : si le code php login.php n'avait accès à la base de données qu'en lecture, on éviterait toute écriture sur la BDB tant que la personne n'est pas identifiée. Ensuite, sur les autres pages php, si une personne attaque, elle a un identifiant donc peut être tracée et surtout ce type d'attaque relève du règlement intérieur de l'établissement… Bref, je ne vois que des avantages à cloisonner un peu mieux les requêtes SQL afin des les rendre plus robuste aux bogues !