- Statut : non résolu
- Ce sujet contient 76 réponses, 5 participants et a été mis à jour pour la dernière fois par
luciole135, le il y a 13 années et 6 mois.
-
AuteurMessages
-
19 juillet 2011 à 9 h 40 min #782506
Ah oui, je patauge dans la gadoue, j’essaie de suite !
Là ça n’affiche rien du tout !
Je vais essayer aussi avec des données encapsulées pour voir !
Ca n’affiche rien non plus, comme si c’était bon ! Bizarre non ?
19 juillet 2011 à 9 h 46 min #782507et en base de données, c’est inséré?
19 juillet 2011 à 9 h 49 min #782508Cela insère les encapsulsation : ‘$vdate’ etc tout simplement, c’est si bête !
19 juillet 2011 à 9 h 53 min #782509🙂 c’est pour ça qu’ils disent d’insérer les données brutes
19 juillet 2011 à 9 h 58 min #782510Oui, tout bêtement, dire que je me prend la tête depuis ce matin pour rien du tout.
Bon alors si $wpdb->insert gère les attaques de type injections SQL, faut-il qu’à la lecture des données dans la base , je protège à nouveau mes variable ou alors c’est inutile ?
19 juillet 2011 à 13 h 02 min #782511chouf1 wrote:Pas certain de ce que tu veux obtenir exactement, mais compte tenu du code que tu donnes, je présume que tu cherches à établir le chemin vers ton plugin ?Depuis 2.6 il existe ces fonctions pour les URL spéciale (tu as ids vieux plugin ?) 😉
site_url()
admin_url()
content_url()
plugins_url()
includes_url()et dans ce cas, la bonne doc est celle-ci:
http://codex.wordpress.org/Determining_Plugin_and_Content_Directories
Non, ce n’est pas ce que je cherche. Cela je sais le faire, je cherche à sécuriser mon plugin en remplaçant les fonctions PHP par des fonctions WordPress.
Ici, Referrer est un lien cliquable à insérer dans une base de données et à reproduire à l’écran pour l’usager telle quelle.
19 juillet 2011 à 13 h 55 min #782512Bon finalement j’ai fais ceci :
$referrer = (isset($_SERVER[‘HTTP_REFERER’]) ? esc_url_raw($_SERVER[‘HTTP_REFERER’]) : »);
$userAgent = (isset($_SERVER[‘HTTP_USER_AGENT’]) ? esc_url_raw($_SERVER[‘HTTP_USER_AGENT’]) : »);Puisque ces valeurs sont juste après stockées dans la BDD, c’est bien cela qu’il faut faire, non ?
Pour l’insertion, je laisse les fonctions mysql_real_escape_string(strip_tags($referrer )) puisque cela évite les injections SQl et les attaques XSS. ce qui donne :
$result = $wpdb->insert( $table_name, array(date=>$vdate,time =>$vtime,ip =>$ipAddress, urlrequested => mysql_real_escape_string(strip_tags($urlRequested)), agent => mysql_real_escape_string(strip_tags($userAgent)) , referrer => mysql_real_escape_string(strip_tags($referrer)), search => mysql_real_escape_string(strip_tags($search_phrase)), nation => luc_Domain($ipAddress) ,os => mysql_real_escape_string(strip_tags($os)), browser => mysql_real_escape_string(strip_tags($browser)), searchengine => strip_tags($searchengine) ,spider => strip_tags($spider), feed => $feed, user => $userdata->user_login, timestamp => $timestamp),
array(‘%s’,’%s’,’%s’,’%s’,’%s’,’%s’,’%s’,’%s’,’%s’,’%s’,’%s’,’%s’,’%s’,’%s’,’%s’ ));Est-ce que comme çà, c’est bien sécurisé ou alors j’ai oublié des trucs ?
Merci de votre éclairage !
19 juillet 2011 à 14 h 09 min #782513Et pour cette fonction :
function luc_StatPress_URL()
{
$urlRequested = (isset($_SERVER[‘QUERY_STRING’]) ? $_SERVER[‘QUERY_STRING’] : »);
if ($urlRequested == « »)
// SEO problem!
$urlRequested = (isset($_SERVER[« REQUEST_URI »]) ? $_SERVER[« REQUEST_URI »] : »);
if (my_substr($urlRequested, 0, 2) == ‘/?’)
$urlRequested = my_substr($urlRequested, 2);
if ($urlRequested == ‘/’)
$urlRequested = »;
return $urlRequested;
}Ne dois-je pas écrire plutôt :
function luc_StatPress_URL()
{
$urlRequested = (isset($_SERVER[‘QUERY_STRING’]) ? esc_attr($_SERVER[‘QUERY_STRING’]) : »);
if ($urlRequested == « »)
// SEO problem!
$urlRequested = (isset($_SERVER[« REQUEST_URI »]) ? esc_attr($_SERVER[« REQUEST_URI »]) : »);
if (my_substr($urlRequested, 0, 2) == ‘/?’)
$urlRequested = my_substr($urlRequested, 2);
if ($urlRequested == ‘/’)
$urlRequested = »;
return $urlRequested;
}Sachant que dans la base de données $urlRequested ressemble à ça (c’est un slug) :
/index.php/how-to-update-definitions-os-browsers-of-statpress-visitors/Cela est stocké dans la BDD, jusqu’au moment où l’administrateur décide d’afficher les pages de stats et alors, cette variable est affichée à l’écran comme étant la page que le visiteur a visité.
J’hésite avec esc_url_raw du coup puisque je stocke dans la BDD !
Bref, je patauge dans la gadoue, je m’y noie dans ces problèmes d’URL et de sécurité, je n’y pige rien !
Ai-je bon ?
19 juillet 2011 à 15 h 25 min #782514je vais regarder ça à tête reposée 🙂
19 juillet 2011 à 15 h 36 min #782515Ah, merci 🙂
Quelle galère que ces URL et la sécurité !
C’est bien plus facile de concevoir des requêtes SQL complexes que de sécuriser un plugin !
19 juillet 2011 à 18 h 47 min #782516chouf1 wrote:Juste une astuce qui vaut ce qu’elle vaut. quant tu rames sur ce genre de détail, va regarder dans les tickets qui sont sur le trac de WP. Tu peux y lire les remontées de bugs, mais aussi tous les échanges entre devs, etcUn search sur esc_url_raw à titre d’exemple: y’a de la lecture !
http://core.trac.wordpress.org/search?q=esc_url_rawMay this help ? :wp:
Merci des liens,
Le problème c’est que je comprends pas très bien l’anglais, cela me fait faire des efforts surhumain pour comprendre une page. Alors j’utilise Google Translate, mais ça traduit mal (mais mieux que moi !). vous n’auriez pas en stock de la doc en français pour le commun des mortels ?Merci 🙂
20 juillet 2011 à 0 h 27 min #782517J’entends parfaitement ce que vous dites, sur mon site j’ai quelques petits tutos comme celui pour insérer un tableau dans WordPress. Je le fais pour aider ceux qui traverseront les même difficultés que moi, pas pour moi car me concernant, ce problème n’en est plus un.
Chaque fois que je passe une difficulté, je fais un petit tuto en français. Je ne m’amuserai pas à l’écrire en anglais. D’autres ont dû le faire avant moi.
Ces petits tutos sont le résumé de mes galères avec WordPress, comment je les ai résolu et une explication la plus détaillée possible du comment il est possible de faire. Vous avez les titres ici :
http://additifstabac.free.fr/index.php/category/wordpress/J’ai même raconté comment j’ai trouvé une requête SQL que j’ai appelé « la requête fictive qui compte zéro l’absence d’enregistrement dans une base de données« . Je n’ai en effet trouvé sur aucun forum anglais ou français comment résoudre ce problème qui à l’air simple et pourtant ne l’est pas tant que ça.
Les programmeurs pensent en PHP, or pour SQL, il faut penser dans la théorie des ensembles. Ce qui est un autre monde. De ce fait, les requêtes SQL des programmeurs PHP sont très maladroites voire totalement inefficaces. La résolution de ce problème en aidera peut-être d’autres, je ne sais pas, je n’ai eu aucun commentaires sur cet article. Peut-être ferez-vous le premier ?
http://additifstabac.free.fr/index.php/sgbd-sql-requete-fictive-compte-absence-enregistrements-base-donnees/Par ailleurs, j’ai passé beaucoup de temps sur le forum à expliquer aux novices le B.A.BA de WordPress, mes galères avec WordPress ont fait de moi un quasi spécialiste.
Alors, je ne pose pas de question par pure fainéantise, mais parce que quand j’ai un problème dans la maintenance d’un plugin, je pose la question tout simplement.
Je prends toutes les réponses, pour autant donner de la doc en anglais sur un site français autant que j’aille voir sur le forum anglais directement.
Ce que vous dites veut-il dire que ce forum n’a même pas lieu d’être ? Que SEUL le forum ANGLAIS est LEGITIME puisque l’on cause INFORMATIQUE ?
C’est cela que vous dites ?
Merci pour les liens.
🙂23 juillet 2011 à 0 h 39 min #782518chouf1 wrote:Mais je tout de même te poser une question: la fonction coalesce ne pourrait pas s’utiliser dans le cas que tu cites ? 😉Si vous parlez de la requête, non, puisque la donnée n’est pas NULL, elle n’existe pas !
Il n’y a aucun enregistrement réel d’un nombre de zéro visite puisque le programme n’enregistre que les visites réelles.
Donc, il est absolument impossible de comparer dans une table, une donnée qui n’existe pas avec une quelconque valeur, que celle-ci soit NULL ou une autre !NULL est une donnée enregistrée, ce qui n’est pas le cas des jours sans visites, il n’y a alors aucun enregistrement dans la table.
Je calcule le nombre (qui est zéro) de visites non enregistrées, je ne peux en aucun cas comparer à NULL, puisque un jour sans visite (donc sans enregistrement) n’est même pas stocké dans la base de données, ni avec NULL, ni avec 0.
On ne peut pas comparer ce qui n’existe pas avec ce qui existe, donc la fonction coalesce n’est ici d’aucune utilité.
Suis-je clair ?
23 juillet 2011 à 7 h 01 min #782520Je n’ai pas lu votre article, mais je crois que les jointures externes peuvent être utiles (sauf si vous les aviez déjà essayées).
Les programmeurs pensent en PHP, or pour SQL, il faut penser dans la théorie des ensembles. Ce qui est un autre monde. De ce fait, les requêtes SQL des programmeurs PHP sont très maladroites voire totalement inefficaces. La résolution de ce problème en aidera peut-être d’autres, je ne sais pas, je n’ai eu aucun commentaires sur cet article. Peut-être ferez-vous le premier ?
http://additifstabac.free.fr/index.php/ … e-donnees/L’on ne peut pas généraliser juste du fait que l’on a trouvé un plugin mal codé.
23 juillet 2011 à 7 h 41 min #782521je ne connais pas la requête originale, mais il me semble que le predicate IN permet de savoir si une valeur est nulle ou pas (retourne vrai ou faux) et retourne null si la valeur n’est pas présente.
-
AuteurMessages
- Vous devez être connecté pour répondre à ce sujet.