Aller au contenu

manmachine

Membre
  • Compteur de contenus

    20
  • Inscrit(e) le

  • Dernière visite

Messages postés par manmachine

  1. Et tant qu'à faire, on évite d'utiliser le $_REQUEST, qui est potentiellement moins sécurisé qu'un $_GET ou un $_POST

    Tiens, et en quoi $_REQUEST serait'il moins sécurisé qu'un $_GET ou un $_POST ?

  2. Si tu veux conserver ton lien en dur type

    <a href="http://domaine.ltd">mon lien</a>

    tu ne peux pas opter pour un script qui comptabilisera le clic coté serveur.

    pour ca du dois avoir un lien en "moux" avec redirection apres l'incrémentation en base de données.

    Pour garder ton lien en dur le mieux est donc d'utiliser du javascript avec l'objet httprequest, en assignat un gestionnaire d'évenement onclick , sur ton lien.

  3. Il plusieurs méthode mais la plus répandues reste celle ci

    1 - ton client n'est pas loggé :

    - tu stock les informations de son panier dans la session

    2- ton client est loggué

    - Si il a rempli son panier en etant pas loggué tu enregistre les informations de son panier en base de données,

    ce qui permet de le sauvergardé pour sa prochaine visite.

    - Tu recré le panier à partir des informations de la bdd

    Pour la table panier c'est pluto simple :

    id du client | id du propduit | date d'ajout | etc ...

  4. Bonsoir,

    si un mail est envoyé individuellement que l'adresse mail du destinataire existe vraiment et que tu indique un return-path alors il n'y a aucune raison pour

    qu'il soit considérer comme du spam. Si certains serveurs ce font blacklister c'est parceque soit effectivement ils spam , soient ils sont utilisé comme relais par des spammeurs ou bien que des spammeur exploite une faille d'un formulaire de contact d'une page web par exemple .

    Il faut aussi pensé au règle de base afin d'éviter des plaintes :

    - pas d'envois de mails à des gens qui ne sont pas inscrit

    - laisser un possibilitée de désincription

    Bref si tu fais les choses dans les règles pas de soucis tu peu tres bien utiliser ton propre serveur.

  5. Les causes peuvent etre multiple , ou ce trouve le fichier que essais d'ouvrir ? n'y a t'il pas un .htacces qui empeche sont ouverture si le user-agent n'est pas autorisé

    etc ... etc ...

    Tu dois donc commencer par tester que tu arrive bien à récupérer le fichier avant tout.

  6. Oui le empty peut faire l'affaire mais vu que dldstyle ne nous présente qu'un petit bout de code je ne sais pas exactement comment il traite cette variable donc je sécurise le test au mieux .

    il faudrait avoir plus d'infos sur le code de dldstyle pour déterminé si un empty suffit

  7. En fait les solutions "maisons" des banques sont en général basé sur ATOS/SIPS , elles comportent elles aussi des backoffices .

    La différence entre PAYBOX et les solutions des banques est a mon avis , le prix , les commissions etc ..

    De plus les banques sont parfois frileuses et refusent tout simplement de fournir une solution de paiement electronique aux petits businness

    alors que paybox fournira le service plus facilement .

    J'ai déjà installer toute sorte de solutions dont PAYBOX, a priori la grande différence est vraiment le cout des transactions et de l'abonnement au service mais je n'ai pas de comparatif à te fournir d'autant plus que c'est le genre que tu peux négocier avec un banquier .

  8. Ton problème vient tu fait que tu fais des unset sur les clés du tableau

    unset($_SESSION['panier'][$key]);

    donc ta variable $_SESSION['panier'] est elle toujours présente .

    donc lorsque tu teste sa présence

    if (!isset($_SESSION['panier'])) {
    echo "<p>IL EST VIDE CE PANIER B***** donc je peux faire session_unset() et session_destroy() </p>";
    } else {
    echo "<p>Normalement il n'est pas vide</p>";
    }

    ta variable existe bien il te répond s donc " Normalement il n'est pas vide " alors qu'il l'est peut etre .

    tu dois donc tester si il sagit d'un tableau et la taille de delui ci.

    if ( is_array($_SESSION['panier']) && sizeof($_SESSION['panier']) > 0  ) {
    echo "<p>Normalement il n'est pas vide</p>";
    } else {
    echo "<p>IL EST VIDE CE PANIER B***** donc je peux faire session_unset() et session_destroy() </p>";
    }

  9. Salut,

    La réponse est simple il n'est pas possible de ne pas recharger une animation flash ( ou n'importe quel élément d'ailleur ) à chaque changement de page sans passer par des frames / iframes ou alors des solutions "type" Ajax .

    L'include PHP est traiter coté serveur qui renvoi donc une page html au navigateur comme si il sagissait d'un seul page.

    Si je comprend bien ton problème ce qui te gène est que ton menu à une sorte d'intro et que la jouer à chaque fois est pénible .

    Pour ca tu peut utiliser une variable que tu passe à ton objet flash apres le premier chargement de ta page pour qu'il ne joue plus cette intro par exemple. Soit en utilisant les cookies , les sessions ou en passant un parametre en mode GET de page en page .

  10. tu peux aligner autant de div que tu veux

    1 - en les placant en absolut et en leur donnant les bonnes coordonnées

    exemple

    .mondiv {
    position:absolute;
    top:0px;
    left: 10px;
    }

    ou bien en les sortant du flux a l'aide de l'instruction float

    <div class="box 1">contenu</div>
    <div class="box 2">contenu</div>
    <div class="box 3">contenu</div>

    en css

    .box {
    float:left;
    }

    ensuite pour restitué le flux sur l'element suivant ces 3 div tu met

    .tonselecteur {
    clear:both;
    }

  11. Le module de base ne fonctionne pas bien , télécharge en un plus récent dans les contributions

    http://www.oscommerce.com/community/contributions

    ensuite pour que le commande soit valider sur ton shop il faut impérativement que le client clique sur le bouton retour à la boutique une fois le paiment effectué , sinon tu n'as pas de retour de la part de paypal . C'est une des grandes faiblesses de paypal .

    Priviligie une solution de paiment avec un retour en socket http.

  12. C'est sur que si tu reste au stade du PHP/SQL tu n'auras pas grand avenir dans le métier mais si tu suis de pret les avancées ( notament dans la POO) ,tu auras toujours du boulot

    c'est vrai que j'aurais du nuancer mes propos, mais c'etait en réaction a la question des scripts clé en main.

    Car si ils vont prendre des part de marché c'est bien dans ce domaine .

    Biensur dire qu'il n'y a pas d'avenir avec des languages est exagéré :wacko: .Mais ca sera de plus en plus dur de s'y faire une place.

  13. Les développeurs web ont-ils un avenir sachant que l'on s'oriente vers des solutions clé en main ???

    Biensur ya de l'avenir , les solutions clé en main on toujours 1 voir 3 trains de retard par rapport aux nouvelles technologies .

    C'est sur que si tu reste au stade du PHP/SQL tu n'auras pas grand avenir dans le métier mais si tu suis de pret les avancées ( notament dans la POO) ,tu auras toujours du boulot .

×
×
  • Créer...