John_attend

Je me foule pas trop si je te dis que ça peut résoudre ton problème de cette manière : A vérifier, essaye d'abord...

Jeronimo > Merci Si je veux modifier le fichier de session par cette méthode c'est parce que je veux modifier le fichier d'un autre utilisateur, pas de l'utilisateur executant le script... Sinon je voudrais utiliser le tableau $_SESSION il faudrait que je change l'utilisateur actuel de session le temps de modifier la valeur et ça ne me plait pas trop...

Désolé du temps de réponse (je passe pas beaucoup sur ce forum et je pensais que quelqu'un te répondrait). As tu vérifié que le chemin était bien le bon ? Il faut que le nom (MonSiteSurLesBananes) dans la commande ci dessous corresponde à un compte existant... cat /home/MonSiteSurLesBananes/www/backup.sql | mysql --host=localhost --user=??? --database=??? --password=??? Mais si ça ne marche pas il existe une autre manière d'exporter ta base de données : mysql --host=?? --user=?? -password=?? base_de_donnees > /home/tonsite/www/backup.sql Tu remarqueras le >, si tu le pointe vers le nom et chemin du fichier, c'est la base de données qui est exportée vers le fichier, si tu le place dans l'autre sens, tu importes le contenu du fichier dans la base de données. Ainsi, pour importer tes données tu feras ceci : mysql --host=?? --user=?? -password=?? base_de_donnees < /home/tonsite/www/backup.sql (mais je l'avais déjà donné dans mon premier message) Vérifie bien le chemin /home/tonsite/www/, il doit être valide sinon bien entendu ça ne fonctionnera pas. Enfin, si tu ne peux pas utiliser de client FTP du type FileZilla, il existe bien entendu les commandes manuelles pour copier le contenu d'un répertoire. En revanche, je ne me souviens plus des noms pour les commandes SSH... Si tu n'as pas encore résolu ton problème, utilises plutôt les deux lignes de commande données ci dessus, notamment la première que je n'avais pas spécifié dans mon premier message.

Oui mais chez OVH y a pas de soucis à ce niveau. J'ai déjà eu des NDD associés à des hébergements chez eux et il m'est arrivé de changer d'hébergeur mais de garder OVH comme registrar.

Pourquoi avec des cookies ? Pourquoi pas avec des sessions ? C'est plus sécurisé, l'utilisateur ne peut pas modifier lui même ses infos, en plus avec les sessions tu n'a pas de limites de types ou de tailles et tu es plus sûr d'être compatible... En plus dans mon cas ça fonctionnera pas car si un utilisateur envoit un message à un autre utilisateur il ne le recevra pas en temps réel car les cookies resteront bloqués sur les informations qu'ils ont eu lors de la connexion. A moins que je n'ai pas tout saisi

Anonymus > J'ai essayé la fonction unserialize, mais aparemment la logique d'organisation d'un fichier de session n'est pas la même, ça n'a pas fonctionné... En fait je vais expliquer mon problème pour comprendre pourquoi j'ai besoin de ça. Je veux créer un espace membre avec un système de messagerie. Pour économiser des ressources, j'utilise les sessions au lieu de rechercher les infos du membres dans la base de données à chaque page, le nombre de nouveaux messages est également récupéré. Toutefois, en cas de réception de nouveaux messages en pleine session, l'utilisateur destinataire doit savoir qu'il a des nouveaux messages, et ceci en temps réel. Alors plutôt que de faire la vérification dans MySQL à chaque page, je préfère modifier le fichier de session du destinataire. Maintenant je me suis créé une classe PHP qui peut récupérer et modifier certaines données d'un fichier de session, certains n'aiment peut être pas la méthode (ce que je comprend), mais ça fonctionne, et ça évite des connexions supplémentaires à la base de données. En tout cas merci de ta réponse, si tu as une autre idée pour mon problème qui peut m'éviter MySQL je suis toujours preneur

Ok, merci de ta réponse

A la place de INT(11) je mettrais un TINYINT(2) En mettant UNSIGNED tu pourras aller de 0 à 255, dans le cas contraire ce sera de -128 à 127 (ou quelque chose du genre). Donc là je mettrais aussi un UNSIGNED quoique dans ton cas si tu ne comptes garder que 22 enregistrements ça changera pas grand chose... Non. Mais à ta place j'utiliserais un champ TIMESTAMP pour enregistrer la date et dans le script PHP j'utiliserais la fonction date() pour resortir la date (tu pourras l'organiser comme tu veux et en plus rajouter des données précises de l'ordre de la seconde). Ou alors tu peux utiliser une expression régulière pour remettre la date dans le bon ordre à partir du format 00-00-0000.

Bonjour à tous, Je cherche à modifier un fichier de session (qui porterait par exemple le nom sess_471516f9e4bd7ffab5449e9b5948da6a) manuellement. Toutefois, un fichier de session a une forme "sérialisée", existe-t-il des fonctions permettant de sérialiser et de déserialiser le contenu d'un fichier de session ? Ou alors doit on faire ça nous même avec des expressions régulières ? Merci d'avance de vos réponses

De toutes façon il ne te coûte rien d'essayer... Et il est vrai que cette solution est assez simple à mettre en place Dans le cas où ça ne fonctionnerait pas (peut être à cause de l'incompatibilité entre la version 3 et 5 de MySQL) tu peux toujours utiliser les commandes suivantes par SSH : Pour exporter les données au format .sql sur ton serveur : cat /home/tonsite/www/backup.sql | mysql --host=localhost --user=??? --database=??? --password=??? (en prenant soin de remplacer par tes données) Pour les importer dans la nouvelle base : mysql --host=?? --user=?? -password=?? base_de_donnees < /home/tonsite/www/backup.sql D'après mes souvenirs OVH explique la technique dans ses guides. Mais avant tout teste la première méthode quand même, tu te compliquera moins la vie. PS : Je ne suis pas un expert de ce type de transfert mais si tu fais un simple copier-coller du contenu du répertoire /mysql/ (normalement constitué de fichiers .MYD .frm .MYI) avec un logiciel du type filezilla en mode sécurisé SSH ça devrait répondre à cette première méthode.

Oui c'est ça, mais je me complique pas trop à définir chaque variable... En fait le script sert à faire comme si REGISTER_GLOBALS était à OFF (alors qu'en fait il est à ON). En fait la méthode que tu me conseille c'est surement l'initialisation ? Mais je préfère ne pas trop me prendre la tête à initialiser chaque variable (un oubli est si vite arrivé).

Je doute très fortement qu'il existe un script à télécharger permettant de faire ça car ce système dépend de ton programme... En gros pour faire un système de parrainnage, tes membres doivent avoir un lien du type http://www.tonsite.com/?parrain=1049, où le nombre 1049 (donné au hasard) doit correspondre au numéro identifiant ton membre (il s'agit en général de la clé primaire). Ainsi, chaque membre a un numéro unique. De plus lorsqu'une personne se rendra sur ton site, tu enregistera le contenu de la variable parrain grâce à un cookies ou une session et si il s'inscrit tu enregistre ce numéro dans un champ parrain de ta table membres. En gros on peut faire comme ça... Ensuite à toi de voir les avantages qu'auront les parrains à avoir des filleuls et là on peut pas t'aider car on ne connait pas ton programme.

Jeromnimo > Merci. Je vois que l'ordre est EGPCS pour $_REQUEST et apparemment en regardant un peu plus bas c'est le même ordre pour register_globals. Je ferais des tests plus profondémment pour m'en assurer. Ce n'est pas vraiment ça en fait, je supprime toutes les $var pour une $_REQUEST[var] donnée, le tableau $_REQUEST lui reste intact. Sinon j'aurais tout simplement fait $_GET = $_POST = $_COOKIE = $_ENV = $_SERVER = NULL; Malheureusement ce serait trop simple... En modifiant les paramètres de register_globals à l'interieur du script il est déjà trop tard car une fois que l'execution commence toutes les variables sont déjà définies... C'est pour ça que je me vois obligé de trouver une autre méthode :-\

Bonjour, J'expose mon problème : afin de créer un sript qui soit compatbile et qui s'adapte selon la configuration du serveur, j'ai créé ce script (à placer en premier) au cas ou l'option register globals serait à ON (je veux qu'elle soit à OFF). <?php foreach($_REQUEST as $key => $val) { ${$key} = NULL; } ?> Ceci afin de supprimer les variable $var pour une $_REQUEST['var'] donnée. Toutefois, je me pose une petite question à propos des register_globals. Celles ci ont un ordre de priorité... En effet, quand celles si sont à ON, si on envoit une variable par POST qui se nomme var et une variable par GET qui se nomme var également, il ne pourra pas y avoir deux $var générée, l'un des supergoblals aura la priorité sur l'autre. Il en est de même pour $_REQUEST... Mais ma question est la suivante : L'ordre de priorité pour les registers_blogals est il le même que pour $_REQUEST ? Car si oui, mon script serait bon, sinon il faudrait que je fasse de même pour chaque Superglobals... Merci d'avance de vos réponses.

Oui mais c'est plus souple à gérer avec la seconde méthode (du moins à ce niveau là). C'est vrai que la première à l'air plus pratique, mais on trouve quand même plus (selon moi) d'avantages pour la seconde. Je ne dis pas que la première n'est pas facilement sécurisable, au contaire, la technique du tableau est imparable, mais ça demande du code en plus qui pourrait être évité : un code plus légé, un script plus rapide, moins de ressources consommées

Bonjour à tous, Dans pas mal d'articles sur certains sites, je lis les manières d'intégrer des "pseudo-frames" avec donc une architecture comme ça : - Sur une page index.php : CHARTE GRAPHIQUE (haut) INCLUSION DE $PAGE .PHP (grâce à une variable dans l'url) CHARTE GRAPHIQUE (bas) Mais pourquoi ne pas faire plutôt : - Sur une page quelconque : INCLUSION DE LA CHARTE GRAPHIQUE (haut) Contenu de la page INCLUSION DE LA CHARTE GRAPHIQUE (bas) Sur beaucoup de sites traitant du PHP la première méthode est expliquée mais rarement la deuxième, pourquoi ça ? Alors qu'en plus la seconde est à mon sens plus sécurisée (on peut sécuriser l'autre mais ça implique un temps de traitement supplémentaire au script), et je ne parle pas du fait que pour la seconde méthode on peut placer du code avant l'affichage de la charte graphique, et pas dans la première. Alors pourquoi une telle explication autour de cette première méthode, quels sont les avantages ? Merci

Oui je sais bien, mais justement, si Flash arrive à interpreter ce code (même dans un fichier .swf) ça veut bien dire que le code est lisible, même si il est crypté dans un fichier .swf, si le lecteur Flahs peut le faire, n'importe qui peut le faire, mais je posais la question parce que je trouvais ça quand même assez louche... Merci de vos réponses

Bonjour à tous, J'ai une petite question à propos de Flash, plus précisemment à propos de l'ActionScript. Flash est intéréssant dans la mesure où l'animation et le script sont interpretés par l'ordinateur de l'internaute (donc économie de ressource pour le serveur du Site Web). Mais dans le cas de l'ActionScript, si celui ci est interprété par l'ordinateur de l'internaute, cela signifie-t-il que dans une certaine mesure ce même internaute peut avoir au code source du script ? (c'est une question importante car certains scripts possèdent parfois des informations sensibles sans parler de l'éventuel pompage de code)... Comment ça se passe à ce niveau ? Merci d'avance

Heu oui en effet j'ai fait une petite erreur (2000 Mo c'est peu pour un site qui a un minimum d'ambition et d'interace graphique). Pour la limitation de trafic au pire après on peut prendre plusieurs espace de stockage mutualisé Enfin, je pense que j'ai eu mes réponses qui ont confirmé ce que je pensais. Merci Mais si d'autres ont des informations à ajouter je suis toujours preneur.

Regardez ce que je viens de trouver : http://www.ovh.com/fr/items/high_availability.xml

Je pensais que si Y aurait il un expert d'OVH ici qui puisse nous expliquer l'architecture de leurs hébergements de mutualisés ? Non, tu n'es limité que par ton trafic, c'est ça qui est bien, tu n'es pas limité par l'utilisation de la RAM (sauf pour des utilsiations anormalement excessives, 25% de la RAM du serveur par exemple pour un seul script).

En effet je pense que par bidouiller wullon voulait signifier que l'on peut faire pas mal de choses avec un dédié (encore faut il en avoir le besoin). Et comme l'a fait remarqué BigVicente, et pour prendre l'exemple d'OVH, le Superplan qui est à 69 (plus cher que le mutualisé que j'ai cité au dessus) n'est pas forcément mieux que le mutalisé... Par contre Nicolas j'aimerais que tu me confirme un de tes propos, non des moindres. Tu dis notamment que . Or, chez OVH (pour reprendre cet exemple), je pensais que chaque site était réparti sur plusieurs serveurs à la fois c'est à dire que si un site bouffe beaucoup tous les autres sites continueront à être répartis en fonction de la consommation des autres de manière à ce qu'il n'y ait jamais de ralentissements. N'y a-t-il pas un répartisseur de charge capable de renvoyer les requêtes sur plusieurs serveurs chez OVH ? Merci de m'éclairer sur ce point

Oui je comprend bien les avantages. On peut faire plus de choses avec un dédié, on a des possibilités illimités. Mais si justement on se fiche de ces possibilités, qu'on à juste besoin d'un site avec MySQL, alors si je comprend bien le mutualisé est mieux Tu dis aussi que le mutualisé reste un compte "partagé". Oui, et alors ? Il est partagé, certes, mais partagé sur des des milliers de serveurs performants (tout dépend de l'hébrgeur mais là je parle d'OVH), et partagés ne signifie pas pour autant que l'on sera limité (sans parler des limites fixées par l'hébergeur) : le site restera rapide étant donné les moyens techniques mis en place derrière.

Bonjour à tous, C'est une question que je me pose en effet... Car je vois par exemple que, chez OVH, avec un XXL plan couplé à un SQL plan on peut avoir : - 2000 MO de transfert / mois - Une base de données allant jusqu'à 1 Go - 100 connexions simultanées pour cette base - 50 autres bases MySQL de 50 Mo avec une limitation de 50 Mo chacune - ... et puis tout le reste compris avec le XXL plan : l'accès SSH, sec. SSL, les sauvegardes et back up accessibles 24h/24 et 7j/7 les disques RAID, les serveurs Bi Xeon..... Le tout pour 54.58 HT par mois Les seules limitations se situent sur le transfert, la taille de la base MySQL et ses connexions simultanées (qui sont élevées même pour un site à fort trafic), le reste (processeur ou autre) vous n'avez pas à vous en soucier. Les hébergements mutualisés utilisent de nombreux serveurs et du matériel haut de gamme. Quand je vois les limitations énumérées ci-dessus et leur prix, tout en sachant qu'en étant sur un mutualisé on peut dormir tranquille niveau sécurité et accessibilité de son site. Je me pose la question des avantages d'un serveur dédié. Surtout quand on a autre chose à faire que de le surveiller chaque jour. Y aurait il ici des personnes qui vont bondir devant mon message et s'empresser de me répondre ? Merci de votre attention.

Ok, merci de tes réponses