IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage PHP Discussion :

Questions divers (cookie vs session)


Sujet :

Langage PHP

  1. #21
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 901
    Points : 79
    Points
    79
    Par défaut
    interessant: [ame]http://www.youtube.com/watch?v=XNnMaYViYHc[/ame]

  2. #22
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    50
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 50
    Points : 37
    Points
    37
    Par défaut
    Tu comptes ouvrir un site international, donc en Anglais, et un site Anglais destiné au UK. Comptes-tu également ouvrir pour une autre population Anglophone (US?).

    Si tu dois utiliser plusieurs "variantes" de la langue Anglaise pour optimiser ta conversion dans les différents pays, tu vas devoir choisir une de ces "variantes" (UK ou US) comme langue de ta version internationale; à ce moment, si tu choisis par exemple UK pour le pays et la version worldwide (WW), alors ne fais qu'une version UK/WW + une version US avec un langage & vocabulaire ciblé.

    Si tu ouvres seulement UK et WW, alors le plus simple est également de n'ouvrir qu'une version car pas de "variante" de langue à adapter => tu ne pose pas de problème de DC et pas de compétition entre tes pages.

    La vidéo que tu as posté explique bien cela: si tu ouvres deux sites e-commerce avec un contenu identique ou très légèrement différent = DC. Pas de pénalité appliquée mais en fait une seule version sera référencée correctement.

    Donc, soit ton contenu est vraiment différent, et parfaitement adapté à ta cible pour que tout soit bien référencé, soit n'ouvres qu'une version si tu n'as qu'un public anglophone.

    En conclusion:

    1. Tu as du UK + US + WW => tu ouvres UK/WW + US ou US/WW + UK (avec une réelle différence de vocabulaire et expression entre les deux sites)

    2. Tu as uniquement UK + WW => tu ouvres UK/WW. Si tu prends un .com pour UK/WW, tu n'auras pas de grosse conséquence si ton SEO est bien construit. C'est seulement un "plus" pour si tu cible uniquement UK.

  3. #23
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 901
    Points : 79
    Points
    79
    Par défaut
    ta version internationale; à ce moment, si tu choisis par exemple UK pour le pays et la version worldwide (WW), alors ne fais qu'une version UK/WW + une version US avec un langage & vocabulaire ciblé.
    je ne comprends pas trop ce que tu veux dire par ca!!
    apres un peu de reflexion, voila ce que je souhaite faire et tu me diras si c'est bon:
    pour l'instant, le site sera en 2 langues et j'aurais 3 URLs:
    my-site.com (par defaut et international)
    my-site.co.uk (vise UNIQUEMENT les anglais)
    mon-site.fr (pour les francais)

    j'ai renommé mes dossier langue en: en-us et fr-fr
    je pense que je dois maintenant creer le dossier en-uk mais qui aura une grande ressemblance au en-us mis a part quelques mots et bien evidement la devise qui sera differente

  4. #24
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    50
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 50
    Points : 37
    Points
    37
    Par défaut
    Si le contenu de my-site.com est bien différent de celui de my-site.co.uk, alors oui tu peux y aller. Si les différences sont minimes, seulement quelques mots changés, mieux vaut ne faire que my-site.com.

    Si les différences ne portent que sur quelques mots changés, Google va l'interpréter comme l'utilisation de synonymes, et va en conclure du DC.

    Conséquence: un de tes sites, my-site.com ou my-site.co.uk, va être "mis de côté" dans le processus de référencement, donc travail inutile.

    La logique de Google: ces deux sites sont presque identiques, on ne va pas afficher les deux dans les résultats de recherche. Celui là semble mieux (.com ou .co.uk), donc on ne parlera que de celui là !

  5. #25
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 901
    Points : 79
    Points
    79
    Par défaut
    le contenu de my-site.com et my-site.co.uk ne peuvent pas etre completement different puisque c'est de l'anglais. comme j'ai dit uniquement le <title> de la page, la devise, frais de livraison et peut etre autres petits elements qui different...

    ca me derange un peu d'utiliser uniquement my-site.com parce que je ciblerai en premier les anglais et ca serai dommage!
    compare http://www.apple.com/ipad/ et http://www.apple.com/uk/ipad/ tu remarquera qu'une tres tres legere difference entre les 2 pages
    comment ca sefait que le site ne soit pas consideré comme du DC?

  6. #26
    Membre expert Avatar de RunCodePhp
    Profil pro
    Inscrit en
    Janvier 2010
    Messages
    2 962
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : Janvier 2010
    Messages : 2 962
    Points : 3 947
    Points
    3 947
    Par défaut
    Salut

    Je n'interviendrais très peu sur le choix technique sur le comment gérer un site multilingue, je réagit juste sur cette question de stocker la langue dans un cookie, qui à mon sens n'est pas envisageable pour la simple raison que les moteurs de recherche (comme Google) n'acceptent pas les cookies, sans compter qu'on ne saura jamais à l'avance si un internaute accepte ou pas les cookies.

    Pour ma part, le stocker dans la session, $_SESSION, et selon certains critères (là ce sera directement lié au choix technique du comment le site sera gérer selon les différents domaines).
    Le gros avantage du tableau $_SESSION c'est qu'il est dispo partout dans le code du faite que c'est une super globale.


    Comme ça, au feeling, je dirais que la définition de ce paramètre de langue devrait être géré avant tout dans le .htaccess, de la réécriture.
    Et encore au feeling, cette réécriture devrait tenir compte du domaine demandé, et vu que la langue est présente dans le nom de domaine (mysite.fr c'est FR, mysite.com c'est EN), il suffirait de la rajouter dans le QUERY_STRING, ça fera que ce paramètre sera coté Php dispo dans le tableau $_GET, ce qui permettra après de le stocker dans $_SESSION.
    Donc théoriquement il ne devrait pas être utile de le rajouter dans l'URL vu qu'il y est déjà.


    Après, selon mes connaissances et les lecture à ce sujet, il y a un autre aspect qui n'a pas été évoqué il me semble, c'est les sous domaines.
    D'après ce que j'ai lu, les sous domaine (fr.mysite.com, en.mysite.com, us.mysite.com) offrirait de bon ou meilleurs résultats au niveau des recherche.
    Mais sous grosse réserve.
    Je dirais qu'il serait bon d'explorer un peu plus cette voie là.
    Mais c'est la technique utilisée dans ton exemple avec apple.com et apple.com/uk.


    Pour la question du comment ça se fait que 2 contenus sensiblement identiques n'est pas considéré comme de la duplication de contenu, là, j'en sais fichetre rien.
    Faudrait déjà être certain que Google a réellement indexé (référencé) ces 2 contenu différents.
    La présence des 2 sites ne veut pas dire que c'est le cas.

    En admettant que ça soit le cas, une recherche sur google.fr par exemple, comme ça tel quel, devrait se faire sur le site apple.com, et non apple/uk.
    Donc une recherche avec des mots clé présents uniquement dans le site apple/uk sera dans ce cas peu ou pas du tout pertinent.
    Ce n'est que lorsqu'on fera des recherche sur www.google.co.uk/ avec les même mots clés ou là ce sera plus pertinents.
    Du moins c'est comme ceci que je le perçois les choses.


    D'où l'importance de se poser la question du comment les utilisateurs exploitent leur moteurs de recherches.
    Pour l'Angleterre par exemple, j'en sais ficherien s'ils exploitent plus google.co.uk plutôt que google.com.

    C'est la même question qu'il faudrait se poser pour un contenu Français.

    Bref ... que de questions.
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  7. #27
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 901
    Points : 79
    Points
    79
    Par défaut
    Bonjour RunCodePhp et bienvenu

    je réagit juste sur cette question de stocker la langue dans un cookie, qui à mon sens n'est pas envisageable pour la simple raison que les moteurs de recherche (comme Google) n'acceptent pas les cookies, sans compter qu'on ne saura jamais à l'avance si un internaute accepte ou pas les cookies.
    c'est vrai, tu as raison! on a completement zapé ce detail! je pense que j'utiliserai un cookie et une session. le cookie pour les prochaines visites et la variable de session pour la visite en cours.
    mais je ne comprends pas trop ce que tu veux dire par google qui n'accepte pas les cookie. google meme utilise des cookies...

    Après, selon mes connaissances et les lecture à ce sujet, il y a un autre aspect qui n'a pas été évoqué il me semble, c'est les sous domaines.
    D'après ce que j'ai lu, les sous domaine (fr.mysite.com, en.mysite.com, us.mysite.com) offrirait de bon ou meilleurs résultats au niveau des recherche.
    Mais sous grosse réserve.
    oullaaaa, c'est pas ce que j'ai lu dans certain forums... il me semble que c'est meme deconseillé!! il vaut mieux utiliser les .tld correspondant au pays pour un referencement optimal.

    En admettant que ça soit le cas, une recherche sur google.fr par exemple, comme ça tel quel, devrait se faire sur le site apple.com, et non apple/uk.
    je viens de faire un test en cherchant sur google.fr le mot "apple" et c'est apple.com/fr qui est en premier. il m'affiche meme apple.fr je pense qu'ils ont le domaine .fr avec une redirection 301
    en faisant la meme recherche sur google.co.uk c'est apple.com/uk qui sort en premier

    D'où l'importance de se poser la question du comment les utilisateurs exploitent leur moteurs de recherches.
    Pour l'Angleterre par exemple, j'en sais ficherien s'ils exploitent plus google.co.uk plutôt que google.com.
    quand tu vas sur google.com, google detecte ton pays et te redirige automatiquement sur le google de ton pays.

    je compte inserer un drapeau pour illustrer la langue, j'ai trouvé ce site pour les telecharger mais est libre de droit? je n'ai pas trouvé cette info!
    http://hawleronline.net/wallpapers/3...try-flags.html

    Meeeeerci

  8. #28
    Membre expert Avatar de RunCodePhp
    Profil pro
    Inscrit en
    Janvier 2010
    Messages
    2 962
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : Janvier 2010
    Messages : 2 962
    Points : 3 947
    Points
    3 947
    Par défaut
    mais je ne comprends pas trop ce que tu veux dire par google qui n'accepte pas les cookie. google meme utilise des cookies...
    Comment ça "utilise des cookies" ?
    Que Google crée un cookie chez toi, oui, mais lorsque lui (googlebot) lancera une requête HTTP vers ton site, et bien si en réponse tu prévois de lui envoyer un cookie, il ne le stockera nulle part, donc n'acceptera pas le cookie.
    Ce qui fait que lorsqu'il lancera une 2ème requête HTTP, le cookie n'y sera pas dans l'entête, ça revient au même que s'il lançait une requête HTTP la 1ère fois.
    En tout ça, sauf erreur, les moteurs de recherche ne stocke nulle part les cookies, donc ne les renvoient pas.
    Puis de toute façon, là ça reste perso, l'intérêt des cookie est extrêmement minime, à part bien sur le cookie correspondant à la session.
    Le seul intérêt que je vois de stocker une info dans un cookie plutôt qu'ailleurs (dans la session par exemple), c'est de vouloir récupérer cette info au-delà de la durée de vie de la session (qui par défaut fait 24 minutes).
    On peu envisager de stocker une info dans un cookie, mettre une durée de 1 mois, et par conséquent pouvoir la récupérer dans cette espace de temps.
    Mais comme par défaut la plupart des navigateurs détruisent les cookie lors de la fermeture du navigateur, ça reste extrêmement aléatoire.
    Pour ma part c'est une surcharge de code limite inutile.
    En tout cas, je ne vois pas où serait le gain pour les langues ici.

    Petite parenthèse au passage concernant PHPSESSID.
    C'est le nom de la session par défaut, elle est définie dans le php.ini
    Mais tu as tout le loisir de donner le nom que tu veux, c'est même largement recommandé, et ça se tout simplement comme ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    session_name('REDHASESSID');
    session_start();
    Juste avant le session_start().


    oullaaaa, c'est pas ce que j'ai lu dans certain forums... il me semble que c'est meme deconseillé!! il vaut mieux utiliser les .tld correspondant au pays pour un referencement optimal.
    Bon, ben de mon coté c'est l'inverse.
    Toi seul sera juge dans cette affaire.


    je viens de faire un test en cherchant sur google.fr le mot "apple" et c'est apple.com/fr qui est en premier...
    Faire des test sur la pertinence sur des mots clés ne se fait pas sur le nom du domaine, pas "apple", mais sur du contenu qui se trouve dans les pages.


    Je pense aussi qu'il y a une redirection 301 sur apple.fr, et quelque part la même technique que d'avoir des sous domaines.
    Dans la pratique on a qu'une seule application, qui elle en général se trouve dans le www, et qui en général est gérer dans le domaine principale, soit mysite.com
    Créer un sous domaine fr.mysite.com qui lui aura comme seul fichier un .hhtaccess qui fera une redirection 301 vers mysite.com/fr n'est pas plus pénalisant, du moins je ne vois pas en quoi cela le serai.

    En tout cas, dans la pratique il peut être utile d'avoir plusieurs sous domaines pour pouvoir gérer chacun de leur coté les contenus linguistique, et ces sous domaines sont en faites totalement transparent pour les utilisateurs vu qu'il y aura de toute manière une redirection vers l'application qui elle est unique (un seul code pour toutes les langues).

    Pour faire court, je ne vois pas la différence, le manque de pertinence, qu'il y aurait entre une URL qui ferait fr.mysite.com et mysite.com/fr ?
    Tout tient à mon avis comment on déclarera les différents sites dans Google (outil Webmaster).
    En faite, on aura défini dans Google que fr.mysite.com ou mysite.com/fr est lié à mysite.fr, et mysite.com à ... mysite.com.
    Au final, j'ai pense même que c'est ni l'un ni l'autre a tord ou raison, ce serait pareil.
    Mais comme ça je dirais que les sous domaines offriraient plus de possibilités dans la manière de gérer les contenus que tout dans 1 seul domaine (répertoire au final).
    Enfin, il y a un aspect que j'ai oublié peut être.


    En tout cas, tu as l'air de plutôt t'orienter vers la présence du paramètre de langue dans l'URL (réécriture derrière), donc mysite.com/fr, et je ne dis pas que ce n'est pas correcte, car beaucoup font ainsi, et si c'était pénalisant ça se saurait.


    quand tu vas sur google.com, google detecte ton pays et te redirige automatiquement sur le google de ton pays.
    Ca ne veut pas dire que c'est la page par défaut de tous les utilisateurs.
    Mais Ok, pour les utilisateur lambda, il y a fort à parier que c'est le cas.
    Mais ne néglige pas la langue par défaut du navigateur, c'est à mon sens celle ci qui a plus d'importance, à défaut d'autres chose.
    Si c'est le Français par défaut, bien qu'il soit à l'étranger, lui offrir directe un contenu en Français me parais plus logique que lui offrir l'Anglais, par exemple.
    Mais c'est mon avis
    De même que la devise n'est pas forcément liée à la situation géographique.
    M'enfin, je suppose que tout pourra être défini de toute façon par l'utilisateur.
    Tout ça n'a pas tant d'importance que ça.
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  9. #29
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 901
    Points : 79
    Points
    79
    Par défaut
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    session_name('REDHASESSID');
    et est ce possible de le mettre dans le .htaccess pour eviter de le mettre dans chaque page ?? majuscule ou minuscule a de l'importance?

    Faire des test sur la pertinence sur des mots clés ne se fait pas sur le nom du domaine, pas "apple", mais sur du contenu qui se trouve dans les pages.
    je n'ai juste pas donné trop de details. ca reste valable aussi si on fait une recherche sur le mot "ipad" ou "macbook pro"...

    Pour faire court, je ne vois pas la différence, le manque de pertinence, qu'il y aurait entre une URL qui ferait fr.mysite.com et mysite.com/fr ?
    je n'ai jamais dit qu'il y a vait une difference entre fr.mysite.com et mysite.com/fr mais par contre il y a une grande difference entre (fr.mysite.com ou mysite.com/fr) et mysite.fr

    En tout cas, tu as l'air de plutôt t'orienter vers la présence du paramètre de langue dans l'URL (réécriture derrière), donc mysite.com/fr, et je ne dis pas que ce n'est pas correcte, car beaucoup font ainsi, et si c'était pénalisant ça se saurait.
    non, pas du tout. si tu regarde mon post #23 tu verras que je veux avoir un .tld par pays:
    my-site.com (par defaut et international)
    my-site.co.uk (vise UNIQUEMENT les anglais)
    mon-site.fr (pour les francais)
    pour faire simple, je ne vais proposer ni langue, ni devise. l'utilisateur aura la possibilité de choisir uniquement le pays (royaume uni: £, france: € et international: $)

    Ca ne veut pas dire que c'est la page par défaut de tous les utilisateurs.
    Mais Ok, pour les utilisateur lambda, il y a fort à parier que c'est le cas.
    t'as raison, je me suis trompé, google te redirige vers le google dans la langue de ton navigateur..

  10. #30
    Membre expert Avatar de RunCodePhp
    Profil pro
    Inscrit en
    Janvier 2010
    Messages
    2 962
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : Janvier 2010
    Messages : 2 962
    Points : 3 947
    Points
    3 947
    Par défaut
    et est ce possible de le mettre dans le .htaccess pour eviter de le mettre dans chaque page ?? majuscule ou minuscule a de l'importance?
    Oui, c'est possible, c'est session.name.
    Mais c'est pas forcement la meilleur chose à faire, il faudrait rationaliser ton code de façon que ce code soit appelé automatiquement, bien souvent un require/include, donc le session_name() + session_start() seront ensemble par exmeple.
    Même chose pour la connexion de la Bdd, on ne répètera pas 100 fois le même code, dans toutes les pages.

    D'ailleurs, vu qu'il s'agit de e-commerce, la gestion des session demande normalement quelque chose de plus poussée que ça, et les gérer dans la Bdd par exemple serait une sécurité supplémentaire, sans compter que ce n'est pas obligatoire qu'il faille démarrer systématiquement la session (y compris donc de définir d'office un nom).

    En ce qui concerne la casse (majuscule/minuscule), ça n'a pas d'importance.
    Disons que par convention (ou règle d'écriture) on met des majuscules, c'est un peu comme les constantes.


    je n'ai jamais dit qu'il y a vait une difference entre fr.mysite.com et mysite.com/fr mais par contre il y a une grande difference entre (fr.mysite.com ou mysite.com/fr) et mysite.fr

    si tu regarde mon post #23 tu verras que je veux avoir un .tld par pays
    A mon avis on a la même vision, c'est juste qu'on dit les choses différemment.
    Mais comme je l'avais dit au tout début de mon 1er post, ce n'est pas un domaine que je maitrise pour conseiller quoi que ce soit.

    Comme ça, je dirais que tout ceci dépendra totalement du comment les différents domaines seront déclarés au niveau de google, dans l'outil Webmaster.
    Il me semble que c'est un ensemble, l'un ne va pas sans l'autre, il ne faut juste se reposer sur les URLs.


    Qu'est ce que tu souhaiterais d'ailleurs faire finalement, ne serait ce au niveau des URLs ?
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  11. #31
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 901
    Points : 79
    Points
    79
    Par défaut
    Mais c'est pas forcement la meilleur chose à faire, il faudrait rationaliser ton code de façon que ce code soit appelé automatiquement, bien souvent un require/include, donc le session_name() + session_start() seront ensemble par exmeple.
    avant je mettais juste session_start() danch chaque page, mais puisque maintenant j'aurai une 2e ligne, je pense que je les mettrai dans un fichier externe et les appeler par un include_once
    la question est la suivant. pour 2 petite ligne de code (seesion_start et session_name) vaut il le coup d'encombrer le serveur par un include???
    j'aurais besoin de session_start dans toutes les pages car j'utilise une variable de session dans toutes mes pages...

    Qu'est ce que tu souhaiterais d'ailleurs faire finalement, ne serait ce au niveau des URLs ?
    le site que je crée sera pour l'instant en 2 langues et l'ideal pour moi c'est d'avoir 3 domaines different:
    my-site.com (anglais par defaut et international)
    my-site.co.uk (british vise UNIQUEMENT les anglais)
    mon-site.fr (francais vise les francais)

    MAIS je ne sais toujours pas trop comment y proceder!!

  12. #32
    Membre expert Avatar de RunCodePhp
    Profil pro
    Inscrit en
    Janvier 2010
    Messages
    2 962
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : Janvier 2010
    Messages : 2 962
    Points : 3 947
    Points
    3 947
    Par défaut
    pour 2 petite ligne de code (seesion_start et session_name) vaut il le coup d'encombrer le serveur par un include???
    Mais faire une connexion de la Bdd est aussi, voir très certainement un code qui devra se faite systématiquement.
    Et hop, voilà comment on rationalise sont code.
    Mais encore, si un utilisateur souhaite changer de langue, et ça, à tout moment, quelque soit la page, il faudra que ce code (le $_GET) puisse être obtenu dans n'importe quelle page. Aller hop, voilà encore une partie de code qui se rajoutera.
    A mon avis, des trucs qui devront se faite au tout début, certains avant que la session ne démarre, d'autres juste après, et ça, quelque soit la page, si on fait la liste il doit en avoir.
    Donc à ce jour tu ne vois que 2 lignes communes, mais pour un e-commerce, il y en a nettement plus que ça normalement.
    C'est le cas pour un mini blog, c'est dire.


    Mais prévoir de démarrer systématiquement la session, et ça tout le temps, et bien le cas des moteurs de recherche (Google entre autre) est un bon exemple.
    La manière de gérer leur cas dépend de la politique que tu voudra mener, et c'est directement lié à la sécurité, et des impératifs que tu te fixeras.
    Je l'avais dit plus haut, Google n'acceptera pas les cookies, du coup, et il me semble que c'est le fonctionnement par défaut de Php, le couple nom/valeur de la session sera automatiquement présent dans toutes les URLs, et ça tout au long de la navigation dans le but de conserver la même session.
    Gros problème, c'est déjà un manque de sécurité car cela facilitera les vols de sessions, de plus, les liens indexés/référencés risqueront contenir le couple nom/session.

    Du coup, la réaction 1ère est de définir de ne plus rien rajouter dans les URLs.
    ceci provoquera un autre problème, à chaque visite, chaque page que Google demandera, une nouvelle session sera créé, et cela va créer autant de nouveaux fichiers que de page que parcourra Google.

    Bref ... au niveau de la gestion des sessions, si on souhaite conserver une bonne sécurité (pas de session dans les URLs tout le long), un fonctionnement adapté selon les cas, ça demande de les gérer soit même, et non pas de manière totalement automatique, ce que prévoit Php par défaut, même si le php.ini offre certaines fonctionnalités.

    Ce qui ce fait très couramment, hormis le fait de les gérer soit même dans sa Bdd, c'est d'avoir une liste de moteurs de recherche, entre autre googlebot, et de le vérifier par rapport au HTTP_USER_AGENT.
    Si c'est googlebot par exemple, alors on ne démarre pas la session.

    Les choses se compliquent un peu plus si ce n'est pas un moteur de recherche, que le HTTP_USER_AGENT ne se trouvant pas parmi la liste, et que supposons l'utilisateur n'accepte pas les cookies.
    Que faire ? car pour la toute 1ère page demandée il sera impossible de le savoir à l'avance.
    On peu continuer comme ça un bon moment.
    (Mais j'arrête là car ça fait déjà beaucoup à mon avis )

    Tu as dans la doc Php un exemple du comment gérer soit même la session :
    session_set_save_handler



    le site que je crée sera pour l'instant en 2 langues et l'ideal pour moi c'est d'avoir 3 domaines different, tout en les conservant dans les fichiers :

    my-site.com (anglais par defaut et international)
    my-site.co.uk (british vise UNIQUEMENT les anglais)
    mon-site.fr (francais vise les francais)

    MAIS je ne sais toujours pas trop comment y proceder!!
    J'en sais trop rien, mais comme ça je dirais qu'il n'y a pas grand chose à faire coté réécriture, voir rien vu que la langue fait partie prenante de l'URL.
    C'est du coté Php, (donc là encore un code commun qui devra se faire dans toutes les page), découper cette l'URL (QUERY_STRING), et récupérer, com, ou co.uk ou fr selon le cas.
    Le mettre pourquoi pas d'office dans la session ($_SESSION).
    Ensuite, se baser sur cette valeur pour récupérer le bon contenu et générer les liens.
    Si c'est fr, alors les liens seront écrits : mon-site.fr/un_produit.html par exemple.
    Enfin, sauf erreur bien sur.

    Ce qui me surprend un peu, c'est : my-site, my-site, mon-site
    Normalement le nom c'est l'entité de l'entreprise, et c'est la même quelque soit la langue.
    La Redoute ou la Fnac ou encore Google c'est le même nom quelque soit la langue, non ?
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  13. #33
    Rédacteur
    Avatar de marcha
    Homme Profil pro
    Développeur Web
    Inscrit en
    Décembre 2003
    Messages
    1 571
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 571
    Points : 2 351
    Points
    2 351
    Par défaut
    Concernant le PHPSESSID, il ne faut pas oublier qu'il est crée avec
    la session et que souvent une session est créée inutilement.

    Petit exemple pour un magasin virtuel:

    Quand on consulte les articles, nul besoin d'avoir une session ouverte.
    C'est seulement quand on ajoute la première fois au caddie qu'il faudrait
    ouvrir la session.

    C'est en voulant afficher que le caddie est vide que l'on ouvre souvent
    accidentellement la session. Au lieu d'ouvrir la session pour constater que
    le caddie n'est pas initialisé en elle, il est possible de vérifier si le cookie de
    session PHPSESSID existe et si il existe pas, on affiche simplement caddie vide et on évite le session_start.

    La première commande d'ajout d'article au caddie lancera le session_start.

    Le moteur de recherche qui parcours le site ne doit pas créer de session.
    Pour cela il suffit de faire des boutons d'ajout au caddie via javascript ou
    via formulaire avec method POST ou de fixer des urls d'action sur le caddie commençant par /caddie/... et de faire une règle dans robot.txt.

    Je ne sais pas si ces concepts sont applicable dans ton site.

    Pour ce qui est de la langue et des multi-domaines, j'aurai tendance
    à proposer te tout mettre sur le .com avec des urls du genre:

    www.site.com/uk-en/...

    et sur le site .co.uk, faire une redirection 301 vers le site.com/uk-en

    EDIT: la langue ne devrait pas être liée au pays. le lien vers le pays sert
    souvent à proposer des produits ou info uniquement disponible pour le
    pays. Il faut pas oublier que des français, allemand, etc... habitent en
    Angleterre.
    Si ton code fait plus d'une ligne, c'est que tu as mal choisi ton langage !

  14. #34
    Membre expert Avatar de RunCodePhp
    Profil pro
    Inscrit en
    Janvier 2010
    Messages
    2 962
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : Janvier 2010
    Messages : 2 962
    Points : 3 947
    Points
    3 947
    Par défaut
    Petit exemple pour un magasin virtuel:

    Quand on consulte les articles, nul besoin d'avoir une session ouverte.
    C'est seulement quand on ajoute la première fois au caddie qu'il faudrait
    ouvrir la session.
    C'est ingérable si on ne démarre pas la session à mon sens.

    Pour exemple, la quasi totalité de boutiques e-commerce affichent dans un coin le nombre de produits dans le caddie, et ça quelque soit la page.
    Sans démarrer la session ça sera impossible de l'afficher vu que tout est dans la session.

    Autre aspect, c'est le temps d'expiration de la session, qui part défaut fait 24 minutes.
    Si on ne démarre pas la session à chaque visite, quelque soit la page, se temps d'expiration ne sera pas reconduit, et si au moment de rajouter un nouveau produit dans le caddie ce temps est expiré, alors le panier sera perdu.
    Pire, si le client est identifié et qu'il lance la procédure de commande, il perdra son panier + son identification.

    Ceux qui pose problème, ce sont les moteurs de recherche et ceux qui sont un peu paranos qui désactivent les cookies, les autres ne poseront aucun problème, donc il y a aucun intérêt à ne pas démarrer la session dans ce dernier cas.
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  15. #35
    Rédacteur
    Avatar de marcha
    Homme Profil pro
    Développeur Web
    Inscrit en
    Décembre 2003
    Messages
    1 571
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 571
    Points : 2 351
    Points
    2 351
    Par défaut
    Citation Envoyé par RunCodePhp Voir le message
    C'est ingérable si on ne démarre pas la session à mon sens.

    Pour exemple, la quasi totalité de boutiques e-commerce affichent dans un coin le nombre de produits dans le caddie, et ça quelque soit la page.
    Sans démarrer la session ça sera impossible de l'afficher vu que tout est dans la session.
    Pas besoin d'afficher le nombre de produit dans le caddie tant que l'utilisateur
    n'en a pas mis. Donc pas besoin de session tant que l'utilisateur n'a pas au
    moins ajouté un produit au caddie. ça n'est pas du tout ingérable.

    Sur ce site par exemple, tu peux te balader dans le catalogue
    sans ouvrir de session. Et pour déterminer si la session est ouverte c'est
    une ligne de code:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    document.cookie.indexOf('PHPSESSID=')!=-1
    Quand il y a pas de session ouverte, pas besoin d'afficher le caddie, ce qui
    évite d'ouvrir la session. Quand l'utilisateur ajoute un élément au caddie
    la session s'ouvre, ce qui fait que le caddie sera affiché par la suite car
    le cookie de session sera détecté.
    Si ton code fait plus d'une ligne, c'est que tu as mal choisi ton langage !

  16. #36
    Membre expert Avatar de RunCodePhp
    Profil pro
    Inscrit en
    Janvier 2010
    Messages
    2 962
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : Janvier 2010
    Messages : 2 962
    Points : 3 947
    Points
    3 947
    Par défaut
    Citation Envoyé par marcha
    Pas besoin d'afficher le nombre de produit dans le caddie tant que l'utilisateur
    n'en a pas mis. Donc pas besoin de session tant que l'utilisateur n'a pas au
    moins ajouté un produit au caddie. ça n'est pas du tout ingérable.
    Bon, ingérable, le mot est surement un peu fort, mais l'exemple de cette boutique me semble plutôt particulier.
    Si on regarde ne serait ce que rapidement, on se rencontre que ces besoins sont réduis au strict minimum.

    Aucune notion de compte client par exemple.
    Il n'est pas multilingue non plus, même si ici ce n'est obligatoirement une donnée persistante.
    Il ne propose rien pour ne serait ce simuler/afficher des tarifs selon le lieu de livraison ou tout autre aspect qui débouche sur des tarifs différents.
    Rien concernant des coupons de réductions ou tout autre opérations dans ce genre.
    Bref, il y a apparemment rien qui demande une certaine persistance tout au long de la navigation, ce qui me semble être plutôt rare.

    Mise à part ça, effectivement on la démonstration que ça peu se faire, en plus d'une gestion du panier avec jQuery.
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  17. #37
    Rédacteur
    Avatar de marcha
    Homme Profil pro
    Développeur Web
    Inscrit en
    Décembre 2003
    Messages
    1 571
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 571
    Points : 2 351
    Points
    2 351
    Par défaut
    Ne nous éloignons pas trop du sujet de départ, càd le
    site de redah75. Je voulais juste lui suggérer de s'assurer
    qu'il ne crée pas une session inutilement avant de se prendre
    la tête à savoir si le PHPSESSID doit être passé comme cookie
    ou dans l'url.
    Si ton code fait plus d'une ligne, c'est que tu as mal choisi ton langage !

  18. #38
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 901
    Points : 79
    Points
    79
    Par défaut
    Bonjour les gars, comment cava?

    apres une loooongues meditation. j'ai decidé de laisser tomber, pour l'instant l'histoire du multidomaine. ca me parait un peu compliqué a installé surtout que ce service n'est proposé par OVH que dans les serveurs mutualisés. si un jour je passe en dédié, tout tombe a l'eau.
    je considere que je passe trop de temps sur cette histoire. je vais donc faire dans une 1ere version du site comme marcha m'a indiqué:
    toujours utilisé le .com et pour le royaume uni, je fais une redirection 301 vers le .com/uk
    le site de Apple duquel je m'inspire enormement n'est pas forement bon. il propose par pays et donc impose une devise par pays. un americain qui habite et se fait livré en france ne peut payer qu'en Euros. j'offrirai donc la possibilité aux internaute de selectionner tout simplement la langue et la devise de leurs choix!

    concernant le panier d'achat, je procederai autrement. je n'utiliserai pas les sessions pour stocker les produits, je les insererai directement dans une bdd...

    je comprends pas vos messages qu'il faut eviter d'appeler le session_start() au maximum afin de ne pas creer le cookie de session. est ce si dangereux que ca??? je compte memoriser le choix de la langue dans une variable de session pour eviter de transmettre toujours la valeur de la langue en GET, j'imagine que c'est deconseillé, hein??

    savoir si le PHPSESSID doit être passé comme cookie
    ou dans l'url.
    c'est clair que je ne le passerai pas dans l'URL mais j'ignorais que c'etait mauvais aussi de l'avoir en cookie!!

  19. #39
    Rédacteur
    Avatar de marcha
    Homme Profil pro
    Développeur Web
    Inscrit en
    Décembre 2003
    Messages
    1 571
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 571
    Points : 2 351
    Points
    2 351
    Par défaut
    Citation Envoyé par redah75 Voir le message
    c'est clair que je ne le passerai pas dans l'URL mais j'ignorais que c'etait mauvais aussi de l'avoir en cookie!!
    sabotage a dit que c'était pas bon que le PHPSESSID soit dans l'url car
    on risque d'avoir une page indexée avec un numéro de session plus valide.

    moi j'ajoute qu'un moteur de recherche qui référencie un site ne devrait
    jamais provoquer l'ouverture d'une session.

    car si pour consulter un site on a besoin d'une session on quitte la règle
    d'unicité entre le contenu et l'url, et c'est ça qui est pas bon pour le
    référencement.
    Si ton code fait plus d'une ligne, c'est que tu as mal choisi ton langage !

  20. #40
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 901
    Points : 79
    Points
    79
    Par défaut
    une question que je me pose:
    faut il mettre tout simplement site.com/en pour l'anglais en general ou plutot site.com/uk ou en-uk pour le royaume uni??

Discussions similaires

  1. [Cookies] Cookies et sessions
    Par TNorth dans le forum Langage
    Réponses: 6
    Dernier message: 19/05/2006, 01h22
  2. [Sécurité] Question de culture sur Session
    Par metalpetsFR dans le forum Langage
    Réponses: 2
    Dernier message: 16/05/2006, 10h42
  3. Réponses: 3
    Dernier message: 01/05/2006, 15h09
  4. [Cookies] PB sessions php et navigation sous imode
    Par hardkmel dans le forum Langage
    Réponses: 8
    Dernier message: 23/12/2005, 13h22
  5. [Cookies] Récupération de cookie de session...
    Par Tizard dans le forum Langage
    Réponses: 1
    Dernier message: 07/12/2005, 15h33

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo