Aller au contenu

Nsg

Actif
  • Compteur de contenus

    12
  • Inscrit(e) le

Réputation sur la communauté

0 Neutre

Information du profil

  • Genre
    Homme
  1. Bonjour Plus une question qu'une réponse : Je trouve que Modx est vraiment adapté dans le cadre de "petits" sites, tant par la rapidité avec laquelle on peut intégrer les visuels ou pour le développement de fonctionnalités un peu spécifiques. Maintenant j'aurai quelques appréhensions à l'utiliser dans le cadre de sites de taille conséquente avec beaucoup de documents/articles, un nombre de d'utilisateurs/rédacteurs qui deviendrait important, une forte fréquentation... Après ces appréhensions sont subjectives puisque je n'ai utiliser Modx que pour des sites de taille modeste. Par contre j'ai cru comprendre que la version 1.0 étendrait sans doute ses fonctionnalités dans ce sens et que la 0.97 apporterait déjà des modifications au niveau de la gestion des utilisateurs - je ne trouve plus les infos des précisions de davidm ? Bon week end Nsg
  2. Bonjour, En dehors des solutions toute faites d'affiliation ou celle de ou les affiliations, on peut en faire un en parsant des flux xml. le principe est assez simple : - les sites de boutique en ligne donnent un accès (restreint) aux fichiers xml générés dynamiquement (rss ou assimilés) et contenant la liste de leur produit avec urls, prix et descriptions. - d'un autre côté le site présentant ces produits récupère régulièrement les flux xml, les parse, met à jour une base de données et affiche les produits. les liens dirige vers un compteur en interne et ce dernier redirige les visiteurs vers la boutique en ligne partenaire. Au niveau des stats les deux parties disposent de compteurs qui peuvent être confrontés. Si les boutiques en ligne partenaires n'ont pas déjà leur système, il faut évidemment s'arranger avec eux pour concevoir un système (en s'inspirant des solutions "standards" existantes tant qu'à faire). A+ Nsg
  3. Bonjiour Il y a WebShare qui sert à se connecter à un serveur FTP via une interface web. L'interface est simple et skinable, ça affiche aussi les miniatures des images, ça lit les mp3, le tout en ajax avec glisser-déposer, etc... Il y a une démo sur le site bref ça peut être très bien pour des clients reste basé sur FTP, qui reste donc utilisable pour les adeptes de FileZilla Ce script sera intégré au panel d'hébergement Gest-HVSL développé par Nuxwin sur la base de vhcs2 donc je pense qu'ils ont un peu regardé au niveau du code et de la sécurité Bon we Nsg
  4. oui, il y a vraiement beaucoup plus simple : avec xslt on transforme un fichier xml en à peut près ce qu'on veut, notamment en d'autres fichiers xml apprendre xslt (pour les transformations) et dtd ou xsl (pour la définition et validation) vont de paire avec l'apprentissage du xml certains aspects sont un peut lourds mais c'est un bon investissement. il y a beaucoup de doc sur xslt sur le net donc je passe les explications sur xslt, surtout qu'ici ça devrait aller tout seul. ici le fichier à transformer (http://www.enseignons.be/services/mail/enseignonsbe.xml) est simple et valide (et un peut "spécial" aussi mais bon) vu la forme des fichiers de contacts msn , et vu qu'on n'a besoin qu'un élément (l'adresse email) le fichier xsl est basique. ici on peut faire avec 2 "templates" (un seul aurait pu suffire) : - un petit correspondant à chaque ligne "Utilisateur" qui va écrire les ligne "contact" avec une commande pour récuperer l'email - un autre correspondant à la racine "Utilisateurs" ou "/" de ton fichier xml initial. ce template va ajouter tout ce qu'il y a au-dessus et au-dessous des ligne contacts ça donne ça : fichier Utilisateurs2msn.xsl <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" version="1.0" indent="yes" encoding="UTF-8" /> <xsl:template match="/"> <messenger> <service name=".NET Messenger Service"> <contactlist> <xsl:apply-templates /> </contactlist> </service> </messenger> </xsl:template> <xsl:template match="Username"> <contact type="1"><xsl:value-of select="." /></contact> </xsl:template> </xsl:stylesheet> Remarques : ici <xsl:value-of select="." /> récupère la valeur de l'élément courant "." == "Utilisateur" <xsl:apply-templates /> est une directive indiquant d'appliquer les autre templates aux élements enfants directs qui se trouvent à l'endroit analogue dans le fichier xml à transformer. cette feuille xslt va maintenant servir a la transformation en un fichier de contact msn pour bien faire il faudrait éventuellement valider le fichier xml avec un shéma xsd et traiter les erreurs... sans ça en php5 (php4 c'est un peu différent) ça se limite au code suivant : $xml = new DOMDocument(); // objet pour fichier xml à transformer $xml->load("enseignonsbe.xml"); // qu'on charge $xsl = new DOMDocument(); // objet pour feuille de style $xsl->load("Utilisateurs2msn.xsl"); $proc = new XSLTProcessor; // nouveau processeur xslt $proc->importStyleSheet($xsl); // qui charge l'objet xml contenant la feuille $proc->transformToURI($xml, 'file:///chemin/contactsMsn.ctt'); // on transforme et on sauve Donc côté php c'est très simple et l'on a pas à écrire un nouveau parser à chaque fois que l'on est confronter à un nouveau type de fichier xml à transformer. Par contre l'écriture des feuilles de style et des shémas sont généralement bien plus complexes qu'ici. Ceci dit il y a beaucoup de fichiers xml définis par des shémas ou dtd "classiques" et on trouve alors souvent des feuilles xslt pour les transformer en d'autres types de fichier. A+ Nsg
  5. Nsg

    Principe de base "tampon"

    Bonjour, si ce n'est pas déjà fait essayes de passer directement du xml à une requête sql (ou un fichier cvs) xml -> confrontation à un xsl ou dtd pour validation -> transformation xslt -> sortie sql ou texte reste ensuite à donner directement la commande générée à mysql (ou faire un load data infile) le tout placé dans un bash sh (éventuellement appelé par php ou cron) il y a par exemple xsltproc comme processeur xml utilisable en ligne de commande (et donc via exec de php) il faut bien sûr avoir les droit suffisant sur l'hébergement mais il y a de grande chance que xsltproc + "load data infile" aille plus vite que php/extention+requête ; et sur 10 minutes de traitement la différence peut être sensible. (maintenant si c'est à faire tous les 36 du mois à 3h du mat c'est peut-être pas la priorité) il semble que TRUNCATE ne prenne pas en compte les transactions en cours, donc un LOCK serait adéquat (et peut être déjà en oeuvre) et si un LOCK/UNLOCK est nécessaire, peut être que quelque secondes peuvent être gagnées en évitant le SELECT et en interchangeant les tables après traitement dex xml > `pt_products_temp`: LOCK TABLES `pt_products` WRITE, `pt_products_temp` WRITE`; RENAME TABLE `pt_products` TO `pt_backup`, `pt_products_temp` TO `pt_products`, `pt_backup` TO `pt_products_temp`; TRUNCATE `pt_products_temp`; UNLOCK TABLES `pt_products`, `pt_products_temp`; ... à voir si le temps d'indisponibilité est plus court (temps total éventuellement plus long car le LOCK va attendre que les transactions en cours se terminent) comme ça a été dit il y a un problème d'index après que la table ait été supprimée puis recrée avec TRUNCATE après quelques recherche j'ai trouvé entre autres ce post qui pourrait expliquer l'erreur sur certaines versions de mysql il semble que ce soit une histoire d'index non "activés" à la recréation qui suit le TRUNCATE, ceci quand ces index ne sont pas PRIMARY ou UNIQUE donc le MATCH qui nécessite un index ne fonctionne plus la solution serait à priori de modifier tes index, car les réactiver avec ANALYSE ou OPTIMIZE TABLE tout de suite après le TRUNCATE ne fonctionnera sans doute pas ("table already up to date...") et le faire après l'insertion de toute les données prendra plus de temps (après un premier enregistrement ça devrait toutefois fonctionner) là aussi c'est à tester... il y a aussi la solution d'upgrader mysql cf au dessus, la commande utilisée par le "Réparer les table" de PhpMyAdmin reconstruit les index entre-autres A+ Nsg
  6. Bonjour, le tout est sans-doute de faire suffisament compliqué pour décourager la plupart de ceux qui voudraient récupérer les fichiers évidemment on peut toujours contourner les protections (d'ailleurs on peut partir du principe que tout ce qui peut être écouté peut aussi être copié) et il y aura toujours des visiteurs qui tenteront (et réussiront) de contourner les systèmes mis en place vu que je dois aussi réaliser un système un tant soi-peut sécurisé dans pas longtemps, j'ai mis en forme quelque notes l'idée de base est de se débrouiller effectuer un minimum de contrôle côté serveur avant de permettre le téléchargement des bonnes playliste par le lecteur flash et de renvoyer une mauvaise playliste si les conditions ne sont pas remplies. rien n'est testé et les bouts de code ne sont là qu'à titre d'illustration, il peut aussi y avoir des problèmes de type cross-site policy selon les cas on pourrait très bien faire plus sécurisé (et surtout plus compliqué) en jouant sur des clé de session et des urls variables... mais bon... donc à priori on peut s'aider de l'user agent du client appelant et l'url de la page appelante (referrer), mais encore une fois les deux peuvent être truquées :-( on peut au moins remplacer le referrer par des sessions php. un test supplémentaire sur HTTP_REFERER serait possible si flash renseigne cette variable à chaque fois (?). 1) sur le serveur on commence par déposer plusieurs playlists xml dans un répertoire non-accessible : - autant de "vraies" playlistes que nécessaire et qui contiennent les url des "bons" fichiers mp3 /var/www/site/protected/playlist1.xml /var/www/site/protected/playlist999.xml - une fausse playliste qui contient l'url d'un fichier mp3 disant "copier c'est pas bien" /var/www/site/protected/fausse-playlist.xml on pourrait aussi se contenter d'une redirection 403/forbidden au lieu de renvoyer une "fausse" playliste 2) sur les pages php où apparaît le lecteur flash, on initialise des sessions et on place une sorte de jeton sur lequel faire une vérification simple (ou très compliquée) ensuite. <?php if(!isset($_SESSION)) { session_start(); $_SESSION['dejavu'] = $_SERVER["REMOTE_ADDR"]; // ici jeton == adresse ip } ?> 3) toujours sur les pages où apparait le lecteur on indique en clair une url virtuelle pour la playlist (c'est plus pratique que de mettre cette adresse en dur dans le code du lecteur qu'il faudrait recompiler à chaque fois) cette url sera ensuite "rewritée" via .htaccess pour rediriger vers un controleur php <object ... <param name="flashvars" value="&playlisturl=http://www.monserveur.com/chemin/playlist1.xml" /> </object> 4) dans le code actionscript du lecteur flash on récupère la variable playlisturl on cré aussi un objet LoadVars qui sera chargé du dialogue avec le serveur et un objet XML destiné à recevoir le contenu de la (vraie ou fausse) playlist var playlistUrl = _root.playlisturl; var playlistLoader:LoadVars = new LoadVars(); var playlistContent:XML = new XML(); playlistContent.ignoreWhite = true; playlistContent.onLoad = playlistOnLoad; // callback car chargement asynchrone 5) quelque part bien caché ailleurs dans le code du lecteur, on ajoute un attribut à playlistLoader qui l'enverra ensuite au controleur php pour vérification playlistLoader.maVariable = "maValeur"; 6) il faut ensuite télécharger une playlist avec playlistLoader qui devra indiquer une chaine "user-agent" spécifique... le soucis est que le plugin flash semble envoyer au serveur la chaîne user-agent du navigateur utilisé :-( -> on peut forger des entêtes HTTP perso avec addRequestHeader() et spécifier une chaine "user-agent" spécifique pour notre lecteur flash var headers:Array = new Array("User-Agent", "Mon-player-flash"); playlistLoader.addRequestHeader(headers); 7) toujours côté lecteur flash il faut maintenant envoyer la requête (ici de type GET) on appelle playlistUrl qui sera "rewrité" en "controleur.php" le résultat sera placé dans l'objet XML playlistContent playlistLoader.sendAndLoad(playlistUrl, playlistContent, "GET"); 8) côté serveur un .htaccess s'occupe donc de rediriger les requêtes sur les playlist*.xml (playlistUrl) vers controleur.php on pourrait faire un premier test sur HTTP_USER_AGENT ici mais ce sera fait dans controleur.php auquel le nom de la playliste demandée est passée en plus de maVariable RewriteCond %{REQUEST_URI} ^/chemin/playlist([0-9]+).xml(.*) RewriteRule ^/chemin/(.*) /chemin2/controleur.php?p=$1 [QSA,L] 9) le controleur php ressemblerait plus ou moins à ça : <?php define('UAGENT', 'Mon-player-flash'); // user-agent du lecteur define('PLAYLISTS_DIR', '/var/www/site/protected/'); // répertoire pour playlists define('FAKE_PL','fausse-playlist.xml'); // fausse playliste define('VARSESSION','dejavu'); // variable de session contenant ip define('VARPASSE','maValeur'); // nom de la variable cachée define('VALPASSE','maValeur'); // valeur de la variable cachée if(!isset($_SESSION)) session_start(); $fichier = PLAYLISTS_DIR . FAKE_PL; // la fausse playlist est envoyée par défaut // expression régulière (sans doute pas bonne) pour le nom des "vraies" playlists $expreg = '/^playlist([0-9]+).xml$/'; if( /* controle de la chaîne user-agent du client */ stristr($_SERVER['HTTP_USER_AGENT'], UAGENT) && /* controle de la session initialisée sur les pages appelantes */ isset($_SESSION[VARSESSION]) && ($_SESSION[VARSESSION] == $_SERVER["REMOTE_ADDR"]) && /* controle de la valeur de variable cachée passée en GET */ isset($_GET[VARPASSE]) && ($_GET[VARPASSE] == VALPASSE) && /* controle de l'existance du nom de la playlist passé en paramètre */ isset($_GET['p']) && (preg_match($expreg, $_GET[p]) > 0)) { // + test éventuel sur le $_SERVER['HTTP_REFERER']; // et si tout semble ok : $fichier = PLAYLISTS_DIR . $_GET[p]; } header("Content-Type: text/xml; charset=UTF-8"); header("Cache-Control: no-cache, must-revalidate"); header("Expires: Mon, 1 Jan 2001 00:00:00 GMT"); header("Pragma: no-cache"); if(@is_file(PLAYLISTS_DIR . $fichier) && (@is_readable(PLAYLISTS_DIR .$fichier))) {@readfile(PLAYLISTS_DIR . $fichier);} else print("<?xml version=\"1.0\" encoding=\"utf-8\"?>\n" . " <playlist>\n" . " </playlist>"); ?> 10) de retour dans le lecteur flash, le gestionnaire playlistOnLoad de l'objet playlistContent prend le relais une fois la playlist xml chargé function playlistOnLoad(success:Boolean) { if (success) { // lecture playlist "vraie" ou "fausse" } else { // traitement si erreur de chargement } } Reste tout le lecteur flash à programmer à moins d'en trouver un en open-source si possible éviter que les mp3 soient mis en cache lors de leur lecture on peut très bien contourner ce système mais pour ma part si j'aime la musique qui passe j'irai peut-être acheter le cd plutôt que de passer du temps à essayer de contourner des systèmes similaires A+ Nsg
  7. Bonjour, Hors eZ Publish, Typo3 (...), Modx fait ça. Ce cms est plutôt orienté "document". chaque doc pourra être un article, une brève, ... ou juste un bout de page pour chaque type de document créé il y a quelque champ prédéfinis : contenu principal, titre long titre court, description, ... Tout l'intérêt est qu'on peut définir plusieurs modèles de doc et pour chacun d'entre-eux définir des champs supplémentaires ("TV" ou template variables). ces champs peuvent être de différents types : texte brut, textet html, fichier, etc. Les rédacteurs pourront ensuite (suivant leurs droits) ajouter des docs via l'interface d'administration et suivant le modèle de doc choisi, un formulaire présentera les TV prédéfinies pour ce modèle l'édition peut aussi se faire depuis le front-end (choix de la TV à éditer via un menu déroulant lorsqu'on est authentifié) L'affichage "basique" d'une page avec ses TV est simple aussi (presque un copier coller d'un modèle html) par contre l'affichage d'ensemble de documents peut être plus complexe suivant ce que l'on veut faire Je trouve qu'il y a quelques points négatifs concernant ces TV (histoire de cardinalité et de recherche) mais dans la mise en oeuvre de Modx est presque reposante par rapport à d'autre cms :-) A+ Nsg
  8. Bonjour, pour un site présentant des extraits d'un album et d'un dvd j'ai d'utilisé "JW Media Player". C'est un lecteur Flash (parmi bien d'autres) dont la licence coûte 15 pour une utilisation commerciale et sous creative common sinon. peu de protection avec ce genre de lecteur flash puisque l'url des pistes ou de la playlist apparaît dans le code html. pour sécuriser un peu la chose je pense modifier le lecteur (source fournie) pour fixer l'url de la playlist directement dans le code actionscript. sinon peut-être restreindre l'accès à la playliste ou aux mp3/fla uniquement pour le lecteur flash. (modif du lecteur pour correspondre à la directive User-Agent spécifique d'un htaccess et lecture depuis une page appelante pré-déterminée) la première solution fonctionnera certainement, je n'ai pas encore testé la deuxième. mais dans les deux cas ça n'empêchera personne de décompiler le lecteur pour ensuite récupérer les fichiers... A+ Nsg
  9. Bonjour, Le fait de répartir un contenu sur plusieurs sous-domaines (ou domaines) n'implique pas obligatoirement de se passer d'une gestion "centralisée" du contenu (ce serait même dommage). Par exemple un cms comme typo3 permet la gestion de plusieurs sites ou différents sous-domaines. (ok typo3 c'est assez lourd mais à la base l'aspect "multidomaine" n'est pas très sorcier si les sites sont sur le même serveur) Une gestion centralisée des données permetterait : - de conserver un "noyau" pour tous les sites et de là conserver une homogénéité (logicielle/structurelle/données/charte graphique générale) - à contrario, d'avoir une certaine latitude pour différencier les rubriques ou sites (droits d'accès, présentation, applications spécifiques, ...) De plus, si la question d'une refonte totale se posait dans 3 ans, la récupération des données serait probablement plus simple avec un seul système plutôt que face à une multitude de sites hétérogènes (la pérénité des données tient aussi à ça). Donc autant opter pour ce type de gestion centralisée à moins que les différentes rubriques/sous-sites soient vraiement trop différents et que ça implique trop de développement. Si cela est possible, répartir sur des sous-domaines ou non est plus une question de lisibilité pour les visteurs ou pour optimiser le référencement. Reste à savoir quels sont, à tous niveaux (contraintes techniques, communication, ...), les convergences et divergences entre les éventuelles rubriques/sous-sites. A+ Nsg
  10. Bonjour, Sur Ebay la solution de paiement Paypal est courante. Mais si tu vends sur ton propre site, et selon le public visé, ces solutions de paiement peuvent être déconcertes pour des acheteurs potentiels. Du coup il y a le risque de rater des ventes qui se seraient peut-être concrétisées en proposant des solutions de paiement plus connues des visiteurs (CB+chèque). Les solutions de paiement en ligne proposées par les banques doivent au moins être étudiées (même pour des prix unitaires peu élevés). Il y a des frais d'accès au service (100 - 150 pour celles que je connais) et un abonnement mensuel (15-20 ), parfois une faible commission sur les ventes. Sans vouloir démoraliser, il m'est arrivé de conseiller à un client de revoir son projet de vente en ligne si le faible coût de ce type abonnemement ne pouvait être supporté : vu l'investissement en temps que la vente en ligne peut demander, autant que ça rapporte un peut plus que 20 . Voir aussi les plateformes de vente en ligne mais l'investissement n'est pas toujours moins important. A+ Nsg
  11. Bonjour, Je ne connais pas solution qui fonctionnera à tous les coups avec un windows.open, même avec des focus et des captures de clics. Par contre tu peux peut-être jeter un oeil sur "Leightbox" qui peut faire apparaître un div et désactiver la page en arrière-plan jusqu'à ce qe l'utilisateur clique sur un lien/image pour faire disparaître le div. Contrairement à "Lightbox" destiné seulement aux images, "leigtbox" permet d'afficher du contenu html. A voir si tu peux t'en inspirer ou le réutiliser, au besoin en atténuant un effet qui serait trop flashy. D'autre scripts tout faits le permettent aussi, voir également des lib ajax (ici c'est basé sur prototype) Ps: s'il s'agit d'ouvrir une page sur un site distant il faudra peut-être l'importer en php pour la placer dans un bloc ou alors se tourner vers autre chose A+ Nsg
  12. Bonjour, désolé de déterrer le topic est-ce qu'il y a un quelconque inconvénient (pour l'activation, mais aussi d'un point de vu légal ou comptable) à acheter un logiciel sur un site US et donc en évitant la TVA en particulier ? ici, en passant par adobe store et en choissant la zone US on a des prix affichés moins élevés qu'en passant par la zone France du même site. par exemple : Creative Suite 3 Design Standard : $ 1.199 soit 888 A+ Nsg
×
×
  • Créer...