SStephane

Si tu cherches un bon livre sur la sécurité en php, je te recommande celui-ci, il date un peu, mais les concepts n'ont pas changé : http://shop.oreilly.com/product/9780596006563.do

Niveau accessibilité c'est moyen, tu ne trouveras ton bonheur à ce sujet que dans les tutoriaux sur le net.

Elude déjà XSS, SQLinject, CSRF et tout ce qui concerne l'upload de fichier, tu auras déjà fait un bon tour d'horizon et évitera les failles potentielles. L'important étant de maîtriser ce que tu fais, sans ajouter de scripts externes et tu ne risques -presque- rien, le reste pouvant être plus vicieux.

Je pense que tu dois pouvoir te contenter de consulter de simples requêtes http, prend simplement garde à bien les sécuriser si les données sont sensibles.

Je dirai que tout dépend des traitements que tu as à faire, si tu as réellement besoin d'échanger des objets et d’interopérabilité etc.

Un peu de lecture : http://www.clever-age.com/veille/blog/soap-vs-rest-choisir-la-bonne-architecture-web-services.html#titre4

Cela dit répondre comme ça est un peu hasardeux sans trop savoir ce qui se cache derrière ton appli. J'ai tendance à utiliser soap par commodité à partir du moment où je dois partager des objets.

Si ton besoin se limite à l'authentification, bof !

Si tu es en full php, tu n'as pas nécessairement besoin de wsdl, cela dit c'est préférable.

Le mieux est donc de créer un webservice (serveur) sur ton serveur A avec une méthode du genre checkUser($username, $password) : cette méthode renverra ce dont tu as besoin sur b, crédits, id user etc., une chaîne json/xml peut faire l'affaire (l'idéal est tout de même de sécuriser l'appel à ce webservice, https & auth).

Selon le retour du webservice sur b, tu ouvres la session etc.

Tu as un exemple à télécharger en bas de page ici

PS : ne fais pas lez wsdl à la main, c'est long et chiant, tu peux le générer facilement avec un composant Zend

C'est pour codeigniter, mais c'est exactement le même principe pour une classe indépendante : ici, si trouves ca pénible d'insérer la bibliothèque zend, tu peux le générer avec netbeans via un plugin.

Bonjour,

Navré pour cette perte de position, mais j'aurai effectivement tendance à penser qu'une intervention manuelle a été effectuée...je ne suis pas référenceur, je donne juste quelques pistes de réflexion et me risque à une réponse...

1) Je remarque en effectuant une recherche https://www.google.fr/search?q=site%3Aplayer.qobuz.com+&ie=utf-8&oe=utf-8&aq=t que peu d'aperçus sont disponibles (note que je ne sais pas si c'est normal, cela ne devrait pas dans la mesure où vous avez suivi les recommandations concernant la navigation ajax cela dit je n'en sais rien).

J'avais travaillé sur un porjet Gaia, il me semble que nous avions des aperçus...

2) Dans les résultats suivants (un exemple mais ils sont nombreux) :

The Essential Jim Reeves The Essential Jim Reeves

The Essential Jim Reeves The Essential Jim Reeves

En description du lien dans la recherche, serait-ce sur-roptimisé ? (d'ailleurs, toutes les descriptions sont +/- identiques hormis les éléments propres à la page - nom de l'artiste, titres...- le ratio (contenu dynamique/statique) n'est peut-être pas suffisament satisfaisant pour passer la barre du duplicate et votre notoriété grandissante (selon vos stats) aurait alerté la hache ? ...supposition...

3) templates jquery : si un pro du référencement peu répondre à l'impact qu'il peuvent avoir sur les moteurs en terme de duplicate(Externalisation p-ê : http://encosia.com/jquery-templates-composite-rendering-and-remote-loading/ )

Intervention qui n'est sans doute pas d'un grand secours, mais le 3) m’intéresse particulièrement

A vue de nez :

SELECT a.* FROM evenements a, evenements_inscrits b, amis c
WHERE c.id_client = b.id_client AND b.id_evenement=a.id
GROUP BY a.id

Pas besoin de réconciliation, j'apprécie déjà ta philosophie et respecte votre travail dont je suis persuadé de la qualité qui fait à coup sur d'Occitech une boite plus que recommandable.

J'ai volontairement placé une pique pour opposer points de vue dirigeant/exe (je suis entre les 2, et n'ai pas de réponse à cette question, soulève l'argumentation inverse sans pour autant la croire ou la défendre ! ).

Dans un monde parfait, il faudrait effectivement que nous -les devs- soyons tous spécialisés, je suis entièrement d'accord. (sous entendu, peu d'agences pourraient donner suite à certaines prétentions salariales parfaitement légitimes au regard de la difficulté et l'investissement qu'il faut pour connaitre un FW sur le bout des doigts, donc SSII... même si l'ambiance y est rarement au beau fixe)

Adhésion également au conseil que tu donnes, car les compétences transverses acquises lors de l'appropriation d'un FW permettent tout de même de passer relativement aisément de l'un à l'autre selon les profils et les frameworks, les concepts sont les mêmes : mvc, routing, orm... (Un dev SF/Cake pourra facilement être qualifié d'expert codeigniter après une semaine de pratique, on parle pas de l'inverse inverse )

SF2 me donne d'assez bonnes perfs et j'apprécie assez doctrine2 ! Je sais qu'il n'a pas été forcément accueilli à bras ouvert ( Voilà un billet intéressant et des commentaires qui ne le sont pas moins : http://www.miximum.fr/tranche_vie/715-symfony-cest-fini%E2%80%A6 )

J'aurai mis cake dans les stars quand même, SF2, c'est une star en france parce que cocorico

Avoir son propose cms ou framework permet d'avoir une maitrise totale de son code et de séparer les couches de developpement; c'est le gros avantage. 

Je déploie eZPublish, et j'en garde néanmoins une maitrise totale, ou presque, et personne n'a jamais répondu à un client que c'était pas possible.

Quant à coder son propre framework ... bof et par vécu en fait : nous avions un framework .NET(1) qui étendait les classes MS et utilisait Hibernate (+ d'autres librairies). Lorsque MS est passé à .NET2, puis 3, qu'hibernate avait évolué (+ les autres libs etc. etc). Nous ne pouvions plus suivre l'évolution du monstre que nous avions nous même crée => poubelle.

**Pire avec PHP : l'apparition des namespaces, du pseudo typage fort**

Utiliser un framework répandu (propriétaire ou open-source) offre tout de même la possibilité aux entreprises de s'épargner les couts de maintenance et d'évolution de celui-ci.

Concernant le fait de masteriser totalement un framework ou de connaitre "un peu chacun", je suis plus mitigé, ça dépend du but recherché.

Peu de gens connaissent parfaitement ZF ou SF2 et ceux dont c'est le cas travaillent souvent pour des boites stables qui ont opté uniquement pour une spécialisation sur ces technos, ce qui semble être le cas d'occitech (très bon framework, cakephp, même si je n'y ai touché qu'une fois -1.2-, et je suis d'ailleurs entièrement d'accord avec ton point de vue et ta philosophie, même si je commente peu ).

La réalité du marché du travail pour un développeur (qui frameworkise), c'est souvent la SSII, et il est préférable pour s'y vendre de connaitre "un peu" 6 technos que très bien une seule (alors "un peu" signifie quand même dire être autonome & auto-apprennant potentiel). On ne devient souvent expert que par accident lorsque l'on a travaillé longuement sur l'un de ces FW au détour d'une mission.

Ces urls ressemblent aux url de redirection de google (les paramètres, d'ailleurs as-tu mis l'url complète ?). Peut être les sites adultes dont tu parles créent des pages satelites contenant des résultats de recherche obtenus via une api quelconque fournie (difficile à dire, tu poses la question mais ne donne pas énormément d'éléments pour répondre ).

En tout cas les paramètres sont semblables à ceux des redirections gg.

Quoi faire ?

- dès qu'une requête http contient ces paramètres (qui doivent être sensiblement toujours les mêmes), regiriger en 301 vers une page correspondante non 404 si tu peux, sinon, vers ton accueil pourquoi pas ?

- ne pas psychoter pour ça si tu n'as rien à craindre

Tu peux faire du flash en utilisant par exemple LocalConnection et ExternalInterface (pas besoin de flex, ni que ton appli soit signée). Tu as sensiblement la même chose en applet.

(Ca parait tordu quand même )

Tu as un plugin jQuery qui s'appelle autocomplete : http://jqueryui.com/demos/autocomplete/

(que je te conseille vivement d'utiliser avec la plus grande parcimonie tant le nombre de requêtes serveur peut devenir violent, que tu utilises jquery ou non).

Plus simplement, si tu ne mets que des <img src="/path/to/images/img.jpg" /> tu n'as pas à t'en soucier, le domaine sera utilisé avant, j'ai toujours trouvé l'adressage relatif hasardeux (../../../../.......) .

Cela pose problème si tu souhaites que ton site soit installé dans un dossier, à ce moment là cf philatex

Le mieux à tout point de vue reste sans aucun doute d'abstraire l'accès à ces fichiers, comme le font la majorité des framework/cms dans leur moteur de template, ex :

symfony : <img src="{{ asset('path/to/images/img.jpg') }}" />

ezpublish : <img src="{'path/to/images/img.jpg'|ezimage()}" />

codeigniter : <img src="<?php echo base_url("path/to/images/img.jpg"); ?>" />

cakephp : <?php echo $html->image('path/to/images/img.jpg'); ?>

Un modèle qui semble faire ses preuves

Sinon, à coup de htaccess pour passer un pansement sur ton souci ressemblerait à :

RewriteRule ^\.\.(.*)\.(jpe?g|png|gif)$ $1.$2 [L]

La balise img contient un attribut longdesc qui peut pointer vers un fichier txt, html, php... (ah l'accessibilité, que du bonheur)

Le plus élégant reste sans doute d'aller piocher le contenu là et de l'afficher à la place de l'image si elle n'existe pas lorsque tu génères ta page en php.

if(!file_exists($img->src) && isset($img->longdesc)){ $alt = file_get_contents($img->longdesc) }

C'est sémantiquement ce qui me paraît le plus correct.

Une requête ajax, ça peut le faire aussi dans un élément caché (qu'éventuellement tu fais apparaître au survol).

$('img').each(function(){
  if(null!=$(this).attr('longdesc') && null!=$(this).attr('longdesc')!='')
  {
    $.ajax({
       url: $(this).attr('longdesc')
       //...
    })
  }
});

Rien ne t'empêche de mettre un 404 ou une redirection dans le else !

A priori, tu pourrais aussi t'en sortir uniquement en htaccess :

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://monsite\.com.* [NC]
RewriteRule \.(gif|jpe?g|png)$ - [F]

Cela dit, c'est facile à contourner en les chargeant à coup de requête, mais je doute que les sites dont tu parles aillent jusque là.

PS, la première technique est plus optimale, mais dans les 2 cas n'oublie pas d'écarter les moteurs des règles htaccess.

tu peux éventuellement afficher tes images en php si les gens ont ouvert une session sur ton site, mais franchement, je ne suis pas certain que ça en vaille la peine (si c'est vraiment gênant parle aux webmaster desdit sites).

sinon, dans tes pages :

$_SESSION['can_view_images'] = true;

dans ton htaccess

RewriteRule ^(.*)\.(jpe?g|png|gif)$ /script_qui_affiche_les_images.php?image=$1.$2 [L,R=302]

dans le /script_qui_affiche_les_images.php :

if(isset($_SESSION['can_view_images']) && $_SESSION['can_view_images']){
header('content-type:image/XXX');
print file_get_contents($_GET['image']); // à adapter et sécuriser
}

Enfin, tu vois l'idée... mais à mon avis, c'est inutile

Une connexion persistante n'est intéressante que si le temps de connexion à ta base de données est long. Tu interroges ta base de données locale, ce temps ne doit donc pas être très long : aucun intérêt d'après moi (si ce n'est de t'obliger à monitorirer davantage ton nombre de connexion pour pas engorger ton SGBD).

SI ta base est sur un serveur tiers, c'est différent. Très franchement, c'est pas que le sujet n'est pas passionnant, mais je n'ai jamais vraiment eu à m'en soucier (même sur de très gros sites), et je pense que la plupart des **sql_pconnect sont le fruit d'un effet de style et non d'un réel intérêt de la part de ceux qui les pondent

Le jour (qui n'arrivera peut être jamais) ou je ferais du tier physiquement, je m'intereesserai peut être davantage à la question !

Cufon est une super alternative http://cufon.shoqolate.com/generate/ en attendant que les butineurs soient plus à jour, en tout cas j'aime assez le concept "déjà tout prêt".

display_errors = off

tout simplement, c'est le cas de la majorité des serveurs de production, tu dois également avoir normalement un log_errors à on dans un fichier de log spécifié ou celui par défaut, c'est ce fichier dont tu dois te servir pour déboguer si tu ne peux pas faire autrement.

$headers = "From: $from\r\n";
$headers.="Return-Path:<name@example.com>\r\n";

mail('machin@machin.com','foo','bar', $headers);

attention quand tu testes si tu utilises la fonction mail() (cf doc : L'en-tête From définit également l'en-tête Return-Path sous Windows )

Dans le mail que tu envois (avant de récupérer un bounce), ajoute des headers du genre :

reply-to : envoyeur@domain.com

return-path: le_mail_qui_gere_les_bounces@domain.com

le_mail_qui_gere_les_bounces@domain.com recevra les bounces (mais pas tous).

Ce que je veux dire, c'est que tu as 2 headers à exploiter prioritairement avant le corps du mail : subject et from par exemple (si subject ou from contient mailer-daemon par exemple).

Ensuite, tu peux éventuellement t'attaquer au body si tu penses qu'un mail est un bounce et qu'il n'est pas reconnu comme tel en le parsant comme tu le fait.

Si ton mail est reconnu comme bounce après tes tests, tu peux tenter de déterminer de quel type de bounce il s'agit selon le status de retour généralement indiqué dans le mail (objet de la 2e méthode que j'ai mise dans ma classe) : http://tools.ietf.org/html/rfc3463

Je ne sais pas ce que ce parser vaut, mais il a l'air plus récent : http://search.cpan.org/~mstevens/Mail-DeliveryStatus-BounceParser-1.530/

Celui que j'ai fait s'inspire un peu de tout, mais il est greffé à ZF, du coup c'est moins évident.

En fait, chaque système de mail te renvoi un peu ce qu'il souhaite, c'est là qu'est l'os (-yapu d'hélice-).

Aussi, je te conseille vivement de découper ta classe et de définir des regex dans des fichiers de configuration.

Ceci à part, s'il s'agit d'une newsletter, ajoute un return-path, ainsi, tu pourras considérer que l'immense majorité des retours à cette adresse sont des bounces.

Pour en revenir à ton souci, je pense que tu ne considères pas les sauts de ligne après delivery :

$body = "This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  qsddqsds46468787qdsqdsq@hotmail.com";

if (preg_match ('/automatically\s[^\n\r]+delivery\s+(.*)?(\S+@\S+\w)/is',$body,$match)) {
echo  "<br> 2 - " . $match[1];
} 

Mais je te déconseille néanmoins ta méthode, tu vas galérer, commence par traiter les entêtes, tu as énormément de chose à exploiter à ce niveau !

voici la méthode inachevée d'une de mes classes qui gère ça si ça peut te mettre sur la voie :

$this->message est un Zend_Mail_Message mais ca se transpose (ZF v1.1)

class LigamsBounceHandler 
{
//...
    /**
     * @var \Zend_Mail_Message
     */
    private $message;

    public function __construct($message) 
    {
        $this->message = $message;
    }
    function isBounce() 
    {
        if(isset($this->bBounce)) return $this->bBounce;
        try
        {
            $this->subject = $this->message->getHeader('Subject');
            if (preg_match("/(mail delivery failed|failure notice|warning: message|delivery status notif|delivery failure|delivery problem|spam eater|returned mail|undeliverable|returned mail|delivery errors|mail status report|mail system error|failure delivery|delivery notification|delivery has failed|undelivered mail|returned email|returning message to sender|returned to sender|message delayed|mdaemon notification|mailserver notification|mail delivery system|nondeliverable mail|mail transaction failed)|auto.{0,20}reply|vacation|(out|away|on holiday).*office/i", $this->subject))
                $this->bBounce = true;
            if ($this->message->headerExists('precedence') && preg_match('/auto_reply/', $this->message->getHeader('Precedence')))
                $this->bBounce = true;
            if (preg_match("/^(postmaster|mailer-daemon)\@?/i", $this->message->getHeader('From')))
                $this->bBounce = true;
        }
        catch(Zend_Mail_Exception $e)
        {
            print ($e->getMessage());
        }
        if(!isset($this->bBounce)) $this->bBounce = false;
        return $this->bBounce;
    }
    //...
    function getStatusCode() 
    {
        if($this->isBounce() || $this->isFeedbackLoop())
        {
            if (preg_match('@Status:\s*([45]\.\d\.\d)@i', $this->message->getContent(), $matches)) {
                    return $matches[1];
            }
        }
        //...
    }
}

Cela existe, tu as dans certaines librairies une gestion très fine des bounces, en voici quelques unes :

/>http://sourceforge.net/projects/bmh/ pour phplist, mais c'est bien d'y jeter un oeil et d'y faire quelques C/C
/>http://anti-spam-man.com/php_bouncehandler/v7.0/ (pas vu depuis un moment)
/>http://www.phpclasses.org/browse/file/11665.html

Serait-ce des apostrophes du genre celle de word ? ( ͗)

Le truc le plus proche de la réalité que j'ai trouvé pour ce type de problème serait de détecter l'encodage en mode strict (sinon c'est trop foireux) :

$isUtf = (bool) mb_detect_encoding($str, 'UTF-8', true);
if(!$isUtf)
  print mb_convert_encoding($str, "ISO-8859-1", "UTF-8");
else print $str;

Tout est alors UTF, si il reste des soucis, quid de tes en-entêtes HTTP (pas ta balise head), de l'encodage de ta page ?