Vous n'êtes pas identifié. Veuillez vous connecter ou vous inscrire.
Sujets actifs Sujets sans réponse
Options de recherche (Page 2 sur 11)
session.php
<?php
session_start();
if(isset($_SESSION['timeout'])
{
$current = time();
// si timeout est stocké en session sous un format d'unix timestamp
$diff = $current - $_SESSION['timeout'];
// session expirée, on peut la détruire complètement ou partiellement
if ($diff > (10*60)) { // 10 minutes
// session expirée
}
}
// session ok et on met a jour la valeur de $_SESSION['timeout']
$_SESSION['timeout'] = time();
?>
Bonjour,
est inutile car tu fais déjà :
Ce code suffit :
$_SESSION = array();
session_destroy();
Pour le code proposé par toad, tu peux le mettre dans un fichier session.php que tu incluras dans toutes tes pages.
gilledunord a écrit:Ce n'est pas parfait non plus, utilise plutot les sessions pour conserver le client_id (pour éviter que quelqu'un s'amuse à changer le code html de tes formulaires et n'envoie un mauvais client_id).
Je ne savais pas que l'on pouvais changer un code html sur un site, la je suis étonné et loin d'imaginais tous ce que l'on peut faire quand on connait les astuces. J'imagine donc que pour le php c'est pareil.
Non, le code php est interprété par le serveur qui renvoie une page html au client.
Admettons que je sois un client malintentionné, je peux modifier le formulaire que je vois sur ta page et utiliser l'idclient de quelqu'un d'autre. Au moment où l'autre client finalisera sa commande, il aura donc de nouveaux produits qu'il n'a pas commandé.
gilledunord a écrit:Pourrais tu voir l'erreur et éventuellement la corriger et me permettre de récupérer le nom avec le prénom du client (nom + prenom donne moins d'erreur que le nom seul) pour obtenir son "idclient" ?
S'est un script récupéré j'ai juste changé les adresses de fichiers
Merci pour ton aide
La session doit être ouverte au début du code php (après le require).
Deux choses importantes :
- la session doit stocker un idclient et non un nom puisque si deux clients ont le même nom tu risques d'avoir des problèmes...
- attention aux injections SQL, il faut contrôler les variables que tu utilises dans les requêtes! C'est bien joli de s'inquiéter à propos des sessions mais il faudrait d'abord commencer par faire un script php robuste.
La gestion de commande en ligne est une chose très sensible au niveau de la sécurité, il ne s'agit pas de créer un livre d'or. Tu devrais te tourner vers des scripts php développés par des personnes qui sont plus renseignées que toi à propos de la sécurité. Je te dis ça pour toi car si tes clients se rendent compte que ton site n'est pas fiable, tu auras une bien mauvaise pub.
Au fait, utilises-tu https ou tout se passe en http ?
@toad : ça pourrait être intéressant mais attention, à la moindre erreur les conséquences seront terribles.
@infobarquee :
le problème c'est que tu ne sais pas à quel moment le client a effectivement abandonné sa commande (ou s'il est allé se faire un café).
La table commande ne peut pas contenir les attributs quantite et idproduit simplement car une commande est composée de plusieurs produits (cardinalité * de chaque côté) donc il faut une nouvelle table tEstCommande qui contiendra trois attributs : idcommande, idproduit et quantite.
Ce n'est pas moi qui veut ça, mais la normalisation (ici on est seulement en 2NF).
Sinon, je suppose que tu veux parler de ODBC mais je vois pas ce que tu veux dire 
infobarquee a écrit:je pensais a une chose, pourquoi ne pas fair eune table relais pour y inscrire les commandes.
apres validation, tu inscrit reellement dans la bonne table et purge l'autre.
je suis pas trop pour les sessions, car si elle n'est pas "fermee" correctement, il peut y avoir usurpation par un autre client ou personne male intentionnée. ce qui peut provoquer un surplus de commande et des erreurs par la suite.
Effectivement les sessions peuvent poser problème mais il existe certaines solutions.
Avec les tables, il y aura un problème si le client ne décide de rien acheter finalement. Dans ce cas il y aure des enregistrements obsolètes dans la table commande.
Pour moi, on ne réalise les enregistrements dans les tables qu'une fois qu'on est sûr que les opérations sont confirmées.
toad a écrit:Et ce n'est pas optimisé, non dans la table com tu as besoin d un champ client_id qui pointe vers client.id.
Et la table com est totalement à revoir... (ex. les produits n'ont rien à faire dans cette table).
Bonsoir,
Si utilises les sessions alors tu n'as pas besoin de la table client lors de la commande. En fait tu ouvres une session pour chaque client et tu sauvegardes la commande dans une variable (toujours en php) et quand le client finalise sa commande, tu enregistres les informations dans la base de données.
Passer l'id client dans un champ hidden d'un formulaire n'est pas sûr car ce champ peut être modifié par un client qui pourra donc faire une commande pour un autre client... (se faire passer pour un autre client).
Avant de commencer à regarder les sessions, tu devrais normaliser ta base de données comme je l'ai expliqué dans ma première réponse.
ps: pas la peine de me vouvoyer
Bonjour,
Je maintiens ce que j'ai dit par rapport aux modifications à effectuer dans la base.
En ce qui concerne ton problème de client, tu pourrais obliger le client à se connecter avant de pouvoir remplir son panier.
Sinon tu peux utiliser un numéro de client unique généré aléatoirement (avec une vérification que ce numéro n'existe pas déjà bien sûr).
Enfin, tu peux utiliser les sessions comme tu l'as précisé : http://www.phpsources.org/tutoriel-sessions.htm
Tu ferais mieux de ne rien enregistrer dans la base tant que le client n'a pas finalisé sa commande.
Tu peux stocker la commande dans une variable session et à la fin enregistrer toutes les infos dans la base.
Bonsoir,
Il te manque une table produit, une table type et une table tEstCommande qui est issu de l'association entre commande et produit et qui stockera la quantité d'un produit commandé.
La table produit contiendra : ref, titre, prix, idtype.
La table type contiendra : idtype, type qui sera un type de produit.
Les clés primaires sont correctes.
Pourquoi avoir choisi le type longtext plutôt que varchar ?
En fait la plupart des SGBD utilise l'expression CREATE INDEX et non pas ALTER TABLE.
Par exemple, c'est le cas pour PostgreSQL et Oracle.
MySQL a introduit l'expression depuis la version 3 mais apparemment les développeurs continuent d'utiliser le ALTER TABLE.
Donc je pense que les développeurs du scripts en question n'ont pas totalement tord d'utiliser CREATE INDEX s'ils ont l'intention de porter leur script sur différents SGBD (un peu de normalisation ça ne fait pas de mal!).
Ceci dit ils auraient pu prévoir un test qui vérifie que le CREATE INDEX est possible pour l'utilisateur et dans le cas contraire utiliser ALTER TABLE.
toad a écrit:Non NooD, il ne suffit pas d'inscrire son site pour être affiché comme 'sécurisé', un scanneur est lancé et check alors ton site, et là tu ne peux pas dire grand chose à part entamer une procédure de 'dispute' des résultats.
Il suffit de faire scanner son site durant la période ou il ne diffuse aucun malware et ensuite publier des malwares puisque ce grand norton n'irait pas voir de lui meme si les informations qu'il a sont à jour, oh grand dieu non.
C'est mieux...
Mais il ne scanne pas tous les sous domaines, si ?
Exact, je n'y avais pas pensé, c'est vrai qu'en général on utilise ALTER TABLE.
La méthode que je te proposais permet simplement de créer l'index directement au moment de la création de la table (ce qui semble logique si on a bien réaliser l'étape d'analyse, d'ailleurs c'est écrit dans la doc ).
Je ne vois pas bien l'intérêt du CREATE INDEX, si ce n'est pour l'utilisateur qui ne peut pas réaliser d'ALTER TABLE...
Peut être y a-t-il une différence chez les autres SGBD (postgresql ou oracle?) ?
Vérifie que tu as bien la dernière version d'@lex guestbook et regarde si ton code php analyse bien les entrées utilisateurs (s'il y en a et même si elles sont invisibles sur la page d'accueil, comme une page admin.php sans mot de passe par exemple).
Je me demande bien qu'elle est l'utilité de ce module pour Norton. Au fond s'il suffit d'inscrire son site pour qu'il soit considéré comme sécurisé...
Et pire, lescigales.org est marqué comme sécurisé donc les utilisateurs qui visiteront les sites malveillants à travers un sous domaine (type moi.lescigales.org) trouveront un site marqué sécurisé par norton!
Les index sont disponibles depuis (au moins) la version 4 de MySQL (cf doc).
En règle générale, la création d'index est autorisée chez la plupart des hébergeurs. Cela fait parti des 'expressions' standards qui sont proposées par défaut avec les SELECT, UPDATE, DELETE et compagnie.
Un index sur une colonne permet d'optimiser les recherches sur cette colonne. En interne MySQL va gérer les données de cette colonne d'une manière particulière afin que les recherches soient plus rapides. Par exemple, pour un catalogue produit, on va effectuer beaucoup de recherches sur le nom du produit. Il est donc préférable d'ajouter un index sur la colonne 'nom du produit'. Je sais pas si c'est aussi clair que la doc
En ce qui concerne les clés primaires, il n'est pas nécessaire de créer un index puisque MySQL (et les autres SGBD) en crée un automatiquement.
Au niveau de l'hébergement, le problème qui peut intervenir si la création d'index est autorisée vient de la mauvaise gestion des créations par les utilisateurs. Par exemple si un utilisateur met des index sur toutes les colonnes et fait beaucoup d'insertions/mise à jour sur ses tables alors les index sont remaniés en permanence ce qui prend beaucoup de temps (c'est la contrepartie du gain de temps lors des SELECT). Mais en règle général, les utilisateurs optimisent bien peu leur base de données...
Tout ça pour faire sa pub au message 12 
Je vois pas le rapport entre Tor et les arnaqueurs. Tor ou pas, il suffit de s'inscrire sous une fausse identité pour rester anonyme... A la rigueur les adresses IP peuvent être intéressante s'il y a des poursuites qui sont envisagées mais j'en doute.
Peut être qu'il faudrait aussi installer un filtre qui bannirait les personnes qui font des fautes tous les trois mots ?
... et pas normal que la génération du zip ou du gzip échoue.
Je crois que l'idée est de redimensionner les images (peut être à la volée) ce qui fera gagner de la place mais à la base il faut pouvoir gérer une image assez lourde et consommer un peu (beaucoup) de CPU.
le plus simple c'est que tu nous montres ton script et que tu donnes une image pour laquelle ton opération a échoué.
Salut Kracus,
Pourquoi ne pas les réduire directement à la sortie de l'appareil ?
D'autant plus que la limite est fixée à 42mo ce qui me paraît plus que nécessaire.
Sinon il y a des scripts qui permettent d'importer et/ou découper les fichiers SQL.
Entre nous, il doit tout à Arnt Gulbrandsen et ses joyeux lurons (Janos Farkas, August Fullford, Ximenes Zalteca et Patrick Michael Kane)...
Enfin je dis ça, je dis rien...
Du moment que la station mire ne tombe pas sur Paris, ah non ça, ça ne s'est pas produit...
ps: Moi qui croyais que se serait en 2038...
Messages trouvés [ 26 à 50 sur 255 ]
Propulsé par PunBB
Currently used extensions: pun_poll, pun_admin_manage_extensions_improved. Copyright © 2008 PunBB