CLASSE DE GESTION D'INTERFACE RÉSEAUX
Utilisateur anonyme
-
19 févr. 2009 à 10:19
cs_hornetbzz Messages postés 59 Date d'inscription lundi 1 décembre 2008 Statut Membre Dernière intervention 3 janvier 2011 - 8 janv. 2010 à 06:02
cs_hornetbzz Messages postés 59 Date d'inscription lundi 1 décembre 2008 Statut Membre Dernière intervention 3 janvier 2011 - 8 janv. 2010 à 06:02
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/49297-classe-de-gestion-d-interface-reseaux
https://codes-sources.commentcamarche.net/source/49297-classe-de-gestion-d-interface-reseaux
8 janv. 2010 à 06:02
if($this->os=="windows") {
Tu peux aussi coder :
if( "windows" == $this->os) {
ça t'évitera des warnings inutiles si $this->os n'est pas définie
2) A propos de ton edit : Compatible Linux en lecture seulement car je n'ai pas encore trouvé comment donner les droits d'exécution à apache.
Il est FORTEMENT déconseillé - par seulement par moi :-) - de donner les droits root au user Apache (il s'appelle en général "guest", "nobody" ou "www", l'affectation des droits s'effectue via un "visudo" sous Nux). Sans quoi tu ouvres la porte à tous les délires possibles. Plutôt dangereux comme approche.
C'est bien codé, mais tous cela s'effectue aussi très bien en shell sous Nux avec la maîtrise de la sécurité. Donc à part pour une utilisation Windows sur les distri type Easyphp ou Wamp, je ne vois pas trop l'intérêt.
J'ai peut être loupé qq chose ..
3) Tu devrais préciser aussi que ta POO est destinée à PHP5. ça ne marchera tel quel pas en PHP4
A+
17 mars 2009 à 19:14
Certaines de ces instructions de traitement (processing instructions) peuvent être nécessaires pour être compatibles avec des filtres XML, ou SSI par exemple, PHP le script PHP n'étant qu'une des mailles de la suite générale des traitements.
D'une façon générale, les tags plus explicites permettent aussi une identification plus sûre du contenu, surtut quand un source n'est plus lui-même associé à un nom avec une extension mais incorporé au sein d'un autre langage ou protocole de transport n'indiquant pas le type de fichier ni son nom.
C'est une bonne pratique de toute façon d'utiliser "<?php" et non "<?" seul qui reste ambigu.
Note: la non reconnaissance des short tags ne concerne pas QUE les vieilles versions de serveurs (d'aileurs ta remarque à propos d'IIS est inappropriée car IIS n'a pas de support de PHP par défaut, et IIS a toujours cette contrainte nécessitant un label pour associer le filtre correct devant traiter le script; et quel que soit l'age d'IIS, on a toujours eu la possibilité d'utiliser l'association de fichier pour désigner le premier filtre). Enfin même PHP lui-même, dans ses versions les plus récentes, peut encore être configuré pour ne PAS autoriser les short tags (l'option de configuration est présente depuis longtemps). La désactivation des shorttags est en fait bien plus souvent faite sur des serveurs Apache qu'IIS, Apache étant largement plus présent pour les serveurs pour le Web public qu'IIS utilisé principalement pour des Intranet et quelques applications métier ou pour des services d'administration locaux de Windows (qui de toute façon se fait plutôt avec des pages ASP, voire JSP, et pratiquement jamais avec PHP, pour des raisons de sécurité où le nombre de moteurs de scripts à maintenir est réduit au strict minimum, le tag "<?" étant alors utilisé pour désigner ce seul moteur de script autorisé et sans aucun chaînage vers un autre moteur ou filtre, toutes les autres PI comme "<?xml" étant passés en transparence complète dans le résultat, ou son contenu totalement filtré si le label de l'extension PI n'est pas explicitement déclaré et autorisé).
C'est donc bien "<?" qui est obsolète et vraiment trop vieux (et partiellement supporté encore, s'il n'est pas tout bonnement supprimé dans une version ultérieure en tant que nuisance) alors que "<?php" est hautement recommandé depuis maintenant longtemps et s'est imposé depuis des années (et sur certains serveurs partagés, l'option désactivant les shorttags est configurée mais pas modifiable du tout), avec un coût vraiment minime (3 caractères, est-ce que ça tue un source?).
Note: on trouve aussi "<?php5" et "<?php4" pour désigner la version de PHP à utiliser (PHP pouvant être lui-même configuré pour indiquer le label qu'il reconnaitra et ceux qu'il ignorera. Un filtre SSI d'Apache peut alors être configuré pour exécuter la bonne version en fonction des PI qu'il trouve dans un source. On trouve aussi "<?perl", "<?SSI", "<?asp", "<?xml", "<?python", etc... et il existe dans PHP des extensions permettant d'utiliser des sous-filtres en amont ou en aval de traitement, ou pour reprendre le traitement du résultat produit après un filtre intermédiaire (qui peut lui-même générer un script PHP dans son résultat, ou retourner des résultats dans divers autres formats indiqués par la signature du label PI en tête du fichier qu'ils produisent.) J'ai même vu "<?text" pour indiquer que toute la suite est du texte brut qui ne doit pas être parsé mais transmis en transparence complète (en ignorant toute présence d'un autre "<?" dedans ou "?>" qui ne doit pas autoriser la reprise de l'analyse lexico-syntaxique.)
10 mars 2009 à 14:15
Par contre ça ne marche que si apache a les droits root pour les commandes concernées.
J'ai mis le resultat des commandes netsh, etc dans des variables publiques pour ne pas avoir à réexécuter les commandes à chaque fois comme le conseillais aKheNathOn, mais je n'arrive pas à les réutiliser dans l'autre classe (enfin bon j'ai pas cherché très longtemps non plus, donc je ferais ptet une autre MaJ plus tard).
J'ai mis des <?php partout dans le index pour vous faire plaisir ;-)
Vous avez raison sur ce point, mais sans vouloir relancer le débat, d'un autre côté je ne connais aucun serveur qui n'accepte pas les shorts tags, à part peut être les vielles versions d'IIS.
2 mars 2009 à 17:26
Il n'y a qu'au début du fichier où on peut garder un "<?php" qui met fin à l'instruction write() implicite (qui n'est éliminée QUE s'il n'y a strictement rien avant).
Le problème du "?>" à la fin est qu'il peut trop facilement y avoir des blancs et sauts de lignes après (parfois ajoutés involontairemet dans les éditeurs par simpel navigation avec les flèches, et que les éditeurs de texte ne suppriment pas non plus automatiquement), et donc cette suite ne sera pas vide et compilera une instruction write() indésirable (qui plantera tout appel ultérieur à header() par exemple)...
2 mars 2009 à 16:48
2 mars 2009 à 16:35
Comme il n'est pas sensé y avoir de suite ni rien de copié dans le corps de la réponse, il est recommandé de ne pas utiliser "?>" du tout, sauf si cette suite est le code complet d'une page HTML quand tous les entêtes HTTP ont été générés, avec des inclusions très réduites de code PHP comme l'affichage de la valeur d'une variable.
21 févr. 2009 à 08:10
19 févr. 2009 à 10:19
A quand une version compatible linux :) ?
Quelques conseils :
La class devrait pouvoir prendre en argument optionnel un paramètre statut pour ne pas avoir à executer pour chaque interface 2 commandes. La fonction getInte... devrait plutôt être une classe de type collection d'interfaces permettant de lister toutes les interfaces. Tu les chargerais dans le construct en indiquant le statut automatiquement à ce moment (ça optimisera le temps d'exécution).
Sinon tu devrait te renseigner sur la fonction popen qui te permettrait de lancer les commandes en mode threadé et par conséquent tu optimisera encore plus le temps d'exécution.
J'irais même plus loin en te disant que le IPConfig /ALL et l'autre commande pourraient tous deux être lancés dans la collection et le résultat stocké dans une variable static publique :
class listeInterfaces {
public static $ipconfig;
public static $netsh;
public function __construct() {
... tu charges le contenu de ces commandes ...
self::$ipconfig = exec...
}
}
class interface {
public function __construct() {
// tu lis le contenu d'un ipconfig :
listeInterfaces::$ipconfig ...
}
}
Bonne prog et à+