WewEB

Bonjour, merci à vous deux pour votre réponse. Mon but est de n'utiliser ce domaine qu'en local, je ne cherche pas à ce que d'autres personnes puissent y accéder; c'est simplement pour pouvoir faire des tests sur un site qui est codé pour ne fonctionner que sur ce domaine. Je pense qu'allier une entrée dans le fichier hosts et la configuration d'Apache. Je teste ça et je vous dis si cela a marché. WewEB

Bonjour à tous, j'aimerais pouvoir utiliser un nom de domaine (attribué ou non) en local. L'idée est de pouvoir rediriger toutes mes requêtes de http://www.domaine.com vers mon serveur Apache. Je souhaite également pouvoir créer des sous-domaines pointant vers des dossiers particuliers. Pourriez-vous m'indiquer le moyen le plus simple de faire cela ? (je pensais utiliser un serveur DNS mais je ne sais pas exactement comment cela fonctionne et si cela répond bien à ma demande) Je suis sous Windows XP. Merci d'avance à ceux qui pourraient m'aider. Cordialement, WewEB

Assez simple à faire. Tu boucles sur ta liste de mot de passes en créant au fur et à mesure un nouveau tableau dans lequel tu replace les mots de passe différents de celui du client. Ca donne: $trouve = false; $ntableau = array(); foreach($contenu as $mdp) { if($mdp == $code) { // Le mot de passe a été trouvé, on ne le rajoute pas au tableau $trouve = true; } else { // Le mot de passe n'a pas été trouvé, on rajoute $mdp au nouveau tableau $ntableau[] = $mdp; } } Voilà, par la suite tu n'as qu'a vérifier si $trouve vaut true pour savoir si le mot de passe était bien dans le fichier. Ensuite, tu généres ce que tu veux écrire avec la fonction explode appliquée à $ntableau. Et tu écris tout ça avec fopen/fputs. Pour revenir sur la question de la sécurité, je te conseille de mettre le fichier pass.txt dans un dossier dans lequel tu places un .htaccess avec écrit dedans "Deny from all". De cette façon, personne ne pourra accéder à ce dossier ni au fichier autrement que par FTP ou par tes scripts exécutés (en gros, depuis la machine). Bonne chance

Bien longtemps que je n'ai pas touché à l'ASP, mais le global.asa, c'est un peu le .htaccess de l'ASP. Va jeter un oeil ici: http://www.asp-magazine.com/fr/asp/blitz/global1.asp (et plus généralement, pas mal d'aide sur Google)

1) Rien d'obligatoire à changer le nom de tes variables, mais si tu n'as plus besoin du contenu des premières, autant les réutiliser... D'ailleurs, tu n'es peut-être pas obligé d'en utiliser autant. $req ="SELECT truc FROM etc..." $req2= mysql QUERY ("$re2") Peut très bien s'écrire: $rs = mysql_query("SELECT truc FROM ..."); Et pour ta requête suivante, tu peux très bien réutiliser $rs (si tu n'as plus besoin de son contenu). Je ne crois pas que ce soit le fait de créer une ou deux variables en trop qui mette à mal ton hébergeur, tu peux donc te permettre de faire comme tu veux de ce point de vue là (mais je préfère personnellement ne pas créer de variable intermédiaire pour y stocker ma requête SQL).

Rien compris, exprime plus clairement ton problème. Et évite de poster des scripts entiers, ça me donne plus envie de fermer la fenêtre qu'autre chose.

Après vérification, pas de souci: http://faq.free.fr/?q=932 A toi de revoir ton code. Il faudrait un peu plus de tests à mon avis (regarder la source de PHPmailer, quand renvoie-t-il une telle erreur ? Comparer ton code aux exemples...)

Y'a pas une erreur là: $mail->$SMTPAuth(true); Ce serait pas $mail->SMTPAuth(true); Ou $mail->$SMTPAuth = true; Vérifie également que Free permet bien d'utiliser SMTP pour envoyer un mail depuis ton site. Du temps où j'y étais, il fallait passer par un de leurs scripts à eux.

Pour effacer un dossier utilise plutôt rmdir. Le dossier à effacer doit être vide, efface donc tous les fichiers qui s'y trouvent avant (une petite boucle et des unlink).

Est-ce le serveur (la machine) ou simplement l'exécutable CS que tu veux relancer ? Deux manières pour rebooter ton serveur CS (pas la machine, juste le prog) Soit te connecter par RCON et utiliser la commande qu'il faut. Voir le post de Valhala (grâce lui soit rendue -aucun rapport, mais ce nom m'évoque uen divinité -) Soit te connecter par SSH à ton serveur, t'identifier et rebooter le serveur (là encore, je ne me rappelle plus de l'exécutable à lancer, mais tu dois savoir ça). Dans la mesure où la première solution ne te plais pas, il ne te reste plus qu'à trouver un script/classe gérant les connexions SSH en PHP (assure-toi aussi que le serveur propose bien une connexion SSH -sous Linux, aucun problème, mais un serveur sous windows... c'est moins sûr) http://www.phpfreaks.com/tutorials/127/0.php

Un $_GET est définitivement inutilisable pour la simple est bonne raison que PHP n'interpréte pas l'url comme un argument. Si tu y tiens vraiment, avec la fonction dont je t'ai parlé précédemment, tu récupéres les arguments que tu mets ensuite dans $_GET... (si vraiment ça te gênes de travailler avec autre chose que $_GET ) Mais c'est pas le plus logique....

Utilise donc la fonction http_decode (trouvable dans les commentaires de la page parse_url) après avoir employé urldecode et parse_url sur $_GET["ref"]. Tu obtiendras un tableau noté $args par exemple et tu pourras alors faire $args["q"]

Je crains de n'avoir pas très bien compris quel était ton probléme. Ces URL te sont passées par argument (ex.: mapage.php?url=monurl) et tu souhaites récupérer des infos dessus ? Quoi qu'il en soit, jette un coup d'oeil là: http://www.php.net/parse_url (ainsi qu'à la fonction http_explode se trouvant dans les commentaires) Et plus généralement: http://www.php.net/url

Sur un serveur correctement configuré, PHP devrait créer les fichiers avec l'utilisateur courant (ici gardencube) non ? Peut-être qu'il les a créés avec un propriétaire différent (ce qui expliquerait que Apache puisse y accéder et toi non). Le plus simple serait de les supprimer avec PHP (un script ou quelque chose pour le faire) et de les recréer à la main.

Bah... sans code on ne peut pas vraiment te conseiller... Il peut y avoir des problèmes de sécurité graves dans un script très simple, comme il peut ne pas y en avoir dans quelque chose de complexe... L'identification par un couple login/mot de passe, si ce couple est unique et stocké dans des variables "en dur" (et non dans une base mysql) parait effectivement moins risqué.