destroyedlolo

Heu, juste une petite precision : tu es sense avoir l'accord de tes visiteurs pour pouvoir generer des stats nominatives (generalement, c'est la petite ligne dans les CGU ou tu autorises ce genre de collecte d'information et ou t'es indique que tu as la possibilite de demander une modification). De meme, il me semble que tout fichier nominatif faire l'objet d'une declaration CNIL.

2 Solutions suivant ce que tu veux faire : Si tu veux que les images n'apparaissent que dans les pages generees par PHP, mais que ce soient quant meme par des liens HTML, la solution est un .htaccess qui n'autorise que les referes depuis tes pages PHP, si tu veux que les images ne puissent etre lues que par PHP, c'est a dire que ce ne sont pas des liens directs sur les images, il te suffit de les placer en dehors de ton arbo html, donc en dehors du DOCUMENT_ROOT, et de les lire par la fonction readfile() de PHP apres avoir generer les headers qui vont bien. Evidement, si tu ne peux les placer en dehors du DOCUMENT_ROOT, tu peux toujours interdire totalement l'acces au repertoire par un .htaccess.

Le langage n'a rien a voir avec la lenteur que tu constates (car je fait tourne mes gros sites sur des machines antédiluviennes et les perfs sont tres bonnes). D'autant plus que 150 references c'est vraiment peu. Pour moi tu as 2 problemes : design generale de l'application : tu devrais commence par te demande si oui ou non tu dois vraiment affiche toutes les references a chaque fois ... paske meme si tu solutionnes tes problemes actuels, c'est reculer pour mieux sauter car un jour ou l'autre, tu rajoutera des references et tu tombera dans le meme travers. Verifie par la meme si tes pages sont bien construites et ne contiennent pas du code inutile. Struturation des donnees : si ta bdd rame avec si peut de donner, c'est qu'elle est mal configuree, mal penser (par exemple au niveau des relations entre tables), et qu'il y manque probablement des indexes. Dans le meme genre, verifie les infos qui sont dedans (une image de couverture par exemple, n'a strictement rien a faire dans une BDD). Pour ta question concernant la mise a jour d'une seul partie de la page, ca ce fait facilement en javascript (recherche autour d'AJAX).

Ce topic revient reguliere et je vais donc faire la meme reponse que d'hab. 1/ c'est pas parce que l'on a un grand ecran que le navigateur prend toute la place (dans mon cas, il reste en 800x600 histoire que je puisse l'activite de mes machines en parallele), 2/ des gens qui n'ont pas forcement des bon yeux utiliser des fontes enorme pour y voir qq chose, meme s'ils utilisent de grosses resolution. 3/ pourquoi ne pas simplement utiliser un design fluide histoire de contenter tout le monde ?

C'est ce que j'ai fait pour mes sites recents (en particulier, pour les clubs photo). Mais mon site perso est en ligne depuis 2002 avec un NdD de DynDNS et j'aimerai le conserver car il n'est pas mal reference au vu du nombre des visites (surtout que je n'ai rien fait pour ca) et j'ai pas mal de visiteurs qui l'on bookmarke. Mais bon, si j'ai vraiment trop de probleme, j'en ferai un sous domaine de clubphotos.fr comme mes autres sites.

Salut, Depuis l'ete, DynDNS ne gere plus les IP statiques en temps que telles. Resultat, hier mon NdD n'etait plus attribue et mon compte a ete supprime dans la foule car un compte est qualifie d'inactif s'il n'y a pas de mise a jour pendant 35j Normalemement, j'aurai du recevoir un mail d'avertissement mais ce ne fut pas le cas Je vais donc bidouille un script de mise a jour d'IP dynamique pour qu'il envoit mon IP fixe tous les 30j a dunDNS (bon, ci qq'un a deja ce gere de script qu'il n'hesite pas a me le dire histoire de gagner un peu de temp). Bye Lolo

Voila. Non, GD travaille en interne avec un format proprietaire et est parfaitement capable de lire une image GIF pour la transformer en JPEG. Le seule truc qui faut faire gaffe, ce sont les limites des differents formats. Par exemple, le GIF est limite a 256 couleurs. Quant au JPEG, il faut faire attention que le taux de compression ne soit pas trop bas, sinon l'image est crade.

Heu non, un input image provoque bien la soumission ... sauf qu'il ne cree pas un $_POST['submit'] mais 2 variables qui contiennent les coordonnes du pointeur de la souris lorsque l'utilisateur a clique sur le bouton. S'il s'agit juste de soumettre un formulaire, j'utilise la methode preconisee par Sarc ... sauf que ca merdoit un peu avec M$-IE (comme d'hab) car il affiche quant meme le value dans le bouton meme si on lui demande d'afficher uniquement l'image Si qq'un a une solution a ce probleme, je suis d'ailleurs preneur.

Arg, t'as de trop bonnes idees Non, pour eux, c'est systematiquement un mail de revalidation. Tien autre trucs qui me viens a l'esprit que j'ai vu sur un serveur FTP : en fait, ce n'est pas le compte qui est mis en quarantaine, mais l'IP d'ou vient l'attaque. Evidement, ca n'evite pas les gros DoS avec moulte PC zombi, mais dans ces cas la, le reseau va s'effondrer bien avant que qq'un arrive a rentrer (j'ai deja eu la situation chez un client).

Pour palier a ce genre d'attaque, une bonne solution est de mettre le compte en quarantaine si par exemple le mot de passe n'est pas entree correctement plus de X fois (3, 5, ...). Pour le revalide, soit il est necessaire de faire une action : - action de la part de l'admin du site (mais ca va vite le gaver), - soit envoyer un EMail en demandant de cliquez sur un lien qui revalide le compte (c'est generalement ce qui est fait), - soit le mettre en quarantaine pour une duree donnee. Cependant, si le gas veut vraiment rentrer, il trouvera toujours une solution ...

Ton systeme peut etre contourne sans trop de probleme. Si tu veux vraiment un truc securise a 200% comme tu le dis, je te conseille tres fortement d'utiliser une authentification HTTP, sur du https, ce qui est la seule methode offrant vraiment un minimum de securite (c'est relativement simple de casser une session). Regarde dans l'historique de mes post, qq'un avait deja pose ce genre de questions. Les versions 2.2 d'apache permettent en theorie une authentification http sur une base de donnee ... sauf que c'est passablement bugger et je n'ai pas reussi a le faire fonctionner, du moins avec PostGRESQL. La solution que je preconise utilise uniquement PHP pour faire l'authentification mais il faut que le serveur soit configurer pour laisser passer le mot de passe.

Heu ... et ca marche ???? Paske une bonne partie des internaute ont une IP differente a chaque fois qu'ils se connectent. Pourquoi leur identifiant ne te suffit pas ?

Y'a meme certaines machines comme les stations SUN qui forcent de fait toutes les cartes a la meme adresse MAC ... adresse MAC qui devient totalement pourrie apres un reboot lorsque la pile de sauvegarde de la machine est naze. Si je ne me trompe pas, cet id changera des que le navigateur sera redemarre ... Donc ca ne permet pas d'identifier une machine. Je pense malheureusement que la seule solution serait l'utilisation de cookie ... avec toutes les limitations que ca impose ...

A moins que tu es un nombre gigantesque d'utilisateurs concurrent, et qu'ils telechargent tous en meme temps, ca m'etonnerai un peu. Dans mon cas, je transforme les images telechargees a la volee avec GD (retaillage, mise d'un watermark, ...) avant de les publier, et vu le peu de ram de mon serveur, ca evite que ca swap ... surtout que je les retaille en 640/480. De plus, beaucoup de mes utilisateurs ont des connections lentes, donc ca evitent qu'ils perdent leur temps pour rien.

Hum, est-ce qu'une association peut payer en CESU ?

Si l'image est plus grosse que la limite que tu as indiques, elle n'est pas creer en fichier temporaire donc il n'est pas possible de la recuperer C'est d'autant plus stupide que le fichier semble bien etre transferer au vu de l'activite reseau que j'ai eu lorsque j'ai fait des testes ...

Oui, mais si la seconde mise a jour echoue aussi ... comment faire pour remettre la liste a un etat correcte ? L'idee que j'ai en tete c'est de forcer le rechargement de la page, mais y'a peut etre mieux non ?

J'imagine que ce ne sont pas des fichiers executables. Dans ce cas, comme l'a dit Dan, le code correcte est 0644. Ca me semble tout a fait normale que tu te face ejecter si tu essaie de les rendre executables ...

J'imagine que ce n'est pas un probleme de resource et que la machine ne swap pas. Hum, je commencerais sans doute par profiler le code PHP pour savoir ou le code passe le plus de temps en vu d'optimisation, car c'est pas forcement normale d'ecraser ce genre de machine. De plus comme t'es sur un dedie, installe PHP en module, car le CGI surtout sur du PHP est un vrais gouffre niveau perf. Le truc ultime si ca ne suffit pas ... serait peut etre de recoder le moteur (donc tout hors IHM), en C++ Ca fait tout redevelopper mais y'aura pas mieux pour les perfs. Bonne chance.

Merci a tous pour cet excellent sujet. Ca fait un moment que je voulais moderniser une de mes interface, et je trouve ici un bon point de depart Une question a propos de Dans la derniere page, il parle avec raison des probleme de rollback ... comment feriez vous pour remetre la liste dans l'ordre dans laquelle elle se trouvait avant la mise a jour qu'a echoue ?

Je rajouterai aussi que s'il s'agit d'un script (Shell, PHP, Perl, ...), il faut aussi verifier que l'interpreteur est correctement configure (genre #!/usr/bin/ksh) et qu'il est lui aussi executable.

Tu peux aussi utiliser umask() si tu veux regler le probleme a la source.

Je pense que c'est potentiellement possible avec une applet. Le serveur n'a qu'a donner les coordonnees de B lorsque A telecharge l'applet, a savoir son adresse IP et eventuellement un port. Le seul bleme, c'est que si le gas passe a travers un firewall, ca ne marchera plus (par exemple, j'ai une freebox configuree en routeur, et a moins d'ajouter une regle dans la conf, aucune machine ne peut se connecter sur ma station).

Pour peu que le service idoine soit lance, tu peux ouvrir une socket sur le port 13 pour recuperer l'heure en clair. (C'est comme ca que je met mon Amiga4000 a l'heure au boot depuis que ca RTC est naze )

Hum, vraiment tres interessant ! Quelle est la version d'Apache que tu utilises ? Perso, j'ai le meme probleme (mais les httpd bloque ne servaient pas forcement google, ca peut etre des visiteurs normaux), mais je pensai que c'etait un bug kernel de NetBSD qui n'est pas hyper stable sur Sparc des que ca swappe. Bref, tien nous au courant.