Hum le gros carré ou il y a marqué direct avec les liens pour les différentes chaines du groupe est pas assez gros ?
Ou il y a une histoire de droits de diffusion spécifique aux 6 nations ? Car le direct fonctionne très bien actuellement.
Je pense plutôt pour ma part que c'est la construction européenne elle même qui fait que c'est un échec : les états européens sont bien trop occupés à chercher à gérer leurs différences (fiscales, sociales, législatives, …) avec les autres membres de cet espace économique pour arriver à défendre leurs intérêts communs au niveau global, face aux autres géants que sont les USA et face aux nouvelles puissances économiques BRICS, car la construction de cet espace économique s'est faite dans le désordre et la précipitation.
Sinon, si les gens ne se reconnaissent pas là dedans c'est surtout et avant tout à cause de l'absence de représentants de l’exécutif (commission européenne) élus sur un modèle démocratique direct.
On a actuellement une belle machine à perdre sans réel parti ou responsables politiques identifiés par la population, sans interlocuteurs à l'international, sans réels projets pour le continent en dehors de ceux de l'OMC et des lobbys qui remplissent les couloirs des institutions. Et surtout sans alternance politique possible.
Bien qu'il doit encore être possible de faire autre chose que de devenir une simple annexe politique des USA en inventant un nouveau modèle démocratique européen, je suis moi aussi assez pessimiste quant à l'avenir de cette union et à sa capacité même à défendre ses propres intérêts.
Je ne suis pas sûr que ton problème vient forcément du driver utilisé pour monter le disque.
Pourrais tu nous donner la sortie de la commande mount (sans arguments/options) pour voir si il est effectivement monté en lecture seule ou si c'est simplement un problème de droits d'accès pour ton utilisateur normal (non root).
Malheureusement pas d'administration système sans droits root.
Quand on exerce ce genre de métiers on se doit tout de même d'avoir une certaine éthique. Un prestataire qui blouserai ses clients - de plus en enfreignant clairement la loi - va très vite s'attirer d'énormes ennuis et disparaître.
La vraie chose dont tu dois te méfier c'est la compétence réelle du presta et sa tarification. Là il est possible et facile de se faire voler en toute légalité.
Sur un système récent et depuis un bon moment maintenant les téléphones de la pomme sont reconnus comme une clé USB.
Mais ton téléphone étant sortit plusieurs mois après ta distribution, pas sur qu'elle le supporte correctement. Une mise à jour du système - qui date quand même de près de 6 ans - devrait te permettre de régler le problème.
Quand Microsoft se pointe dans un cab ministeriel et explique "salut, je représente des dizaines de milliers d'emplois, et au fait je finance des startup, je file des licences gratuites, des partenariats qui vont bien .. - bref je te refais pas le tableau- " je pense que ça demande quand même de sacrées cojones pour poser le débat et écouter ce que nous autres avons à dire.
L'état est dans ce cas aussi un très gros client avec d'énormes moyens concentrés aujourd'hui vers ces sociétés. Cela devrait lui donner le poids nécessaire pour avoir la main sur les logiciels qu'il utilise si seulement il le décidait que ce soit avec ou sans ses partenaires actuels.
Si le problème était seulement économique ce n'en serait pas un. La sécurité nationale, les écoutes, la capacité du pays d'avoir une indépendance par rapport aux géants américains… tout cela est lié.
La forme que peut prendre une guerre moderne devrait un peu plus nous inquiéter sur toutes ces questions.
Malheureusement à force de manquer de cojones, comme tu le dit très bien, j'ai l'impression qu'on a abandonné une idée qui a fait la force ce pays et a permis de faire travailler pendant des décennies ses cerveaux sur des technologies de pointe, celle d'une certaine forme d'indépendance.
Il y a tout de même différentes catégories de couteaux… poignarder quelqu'un avec le couteau à pain c'est pas super facile. Couper le pain avec un poignard non plus ^^.
Pour le serveur ts, si il est installé par un package cela réglera le problème. Sinon il faudra faire un chown manuellement en se limitant cette fois à son emplacement d'installation.
Juste pour information tu as un bouton en dessous des commentaires qui te permet de répondre aux commentaires dans le fil, c'est plus lisible et les personnes auxquelles tu réponds reçoivent une notification ;)
Non mais c'est une blague… Je te pose des questions tout de même assez précises pour avoir une idée dont devrait fonctionner ton système merveilleux et tu te contente de me balancer des liens sur le fonctionnement de tex.
Si pour toi il est si facilement possible de faire mieux que ce qui existe, c'est que tu as bien une idée sur la façon dont l'abstraction devrait fonctionner dans le langage en dehors du type fragment sql / chaine non sécurisée quand les données proviennent de l'entrée utilisateur dont tu nous as parlé non ?
Question de niveau d'abstraction. Linq montre qu'on peut avoir des abstractions simples et puissantes.
Puissance limitée tout de même : LINQ ne gère pas, par exemple, les requêtes récursives en SQL. Donc il va falloir contourner un problème qui n'a aucune raison d'exister si par malheur tu en as besoin. Pour cela et pour les raisons évoquées précédemment ce n'est certainement pas la solution universelle.
Mais à l'origine on parlait de langage "hôte" et de langage "clients" histoire d'éviter les collisions de langage, genre garantir qu'une entrée utilisateur ne va pas injecter de SQL dans une requête construite en SQL.
Euh oui enfin c'est tout de même toi qui est venu avec LINQ pour exemple et qui propose justement de se débarrasser complètement de la query string SQL pour régler ce problème.
La nécessité pour garantir ça n'implique pas du tout qu'on perde en puissance dans l'expressivité de la dite requête construite en SQL résultante, "juste" qu'on soit capable d'assurer la traçabilité des données utilisateurs entre le moment où ce sont de simple chaînes de caractère et le moment ou on les fait basculer dans le monde du SQL. Et qu'au moment de cette bascule, on soit capable d'assurer que ces chaîne entrée utilisateurs ne vont pas se faire interpréter comme des bouts du langage client (SQL dans notre cas) et donc que l'escaping ait bien été effectué.
.
Ça n'implique pas du tout qu'on fasse perdre des moyens d'optimiser le SQL si on en reste là dans les principes. C'est uniquement parce que le problème est mal dévoupé et qu'on mélange différents niveau/problème qu'on peut perdre à certains autre niveau, ça n'implique pas du tout que ce soit une fatalité de l'abstraction de problème en soit. Au contraire en fait, souvent on abstrait certaines données du problème qui ne sont pas pertinentes pour ce qu'on veut résoudre pour séparer plus facilement les problèmes …
Le problème est bien là : entre ajouter une petite fonction native gérant un sprintf et du safe_escape sur des données typées pour finalement les insérer là où tu veux dans une query string et une intégration au langage comme LINQ il y a un monde et il n'est pas évident de savoir où tu mets le curseur pour définir ce fameux système de sécurisation des requêtes universel qui conviendra à tous les usages.
Pardonne moi mais ça c'est encore une bêtise, tu as lu les papiers que cite https://linuxfr.org/news/tex-et-traitement-de-donnees-par-flot-e01-lire-du-tex ? Je te le conseille, tu verrais qu'il existe des langages dont les macros travaillent au niveau de la grammaire du langage de l'interpréteur, ce qui est un niveau d'abstraction assez élevé et pertinent, qui permettent d'offrir énormément de souplesse sans avoir à se battre avec l'interpréteur puisqu'il est prévu pour.
Mes propos concernaient là encore les manques de LINQ, maintenant tu viens me parler de Tex…
De quelle façon tu comptes te servir concrètement d'un tel système pour gérer la problématique évoquée ?
Je ne suis d'ailleurs pas non plus convaincu, à la base, qu'il soit si pertinent de vouloir mixer deux choses très différentes : un langage de programmation et un langage de requête dans une syntaxe commune qui n'exprime pas clairement ce qui sera envoyé au serveur.
Ah oui point très important sur lequel je n'ai pas répondu pour terminer :
La diversité est une force et non une faiblesse, tout comme dans le LL en général.
Système élégant et puissant ne signifie pas pour autant réponse universelle, surtout dans le cadre d'une problématique aussi complexe que la gestion de la communication avec une base de données et plus spécialement dans le cas de SQL qui possède de nombreuses variantes.
LINQ, par exemple peut poser de nombreux problèmes notamment pour optimiser une requête lorsque tu n'as pas réellement la main dessus.
On déplace la complexité à un autre niveau sans pour autant avoir un contrôle direct dessus. En tout cas bien moins facilement qu'avec une bibliothèque écrite dans le même langage, qui peut être propre au projet, et facilement modifiable à souhait.
Quand on dépend directement de l'interpréteur, c'est tout de même beaucoup moins souple si l'on souhaite étendre le système ou faire la moindre adaptation sur son comportement.
Oui, on est pas d'accord, ce n'est pas grave. Après je te réponds poliment, en argumentant. Si cela t'embêtes effectivement mieux vaut arrêter.
Tu regardes cela d'un point de vue trop théorique selon moi, comme si l'on construisait aujourd'hui une application complète en partant avec comme seule base ce qui est nativement dans le langage.
Dans la pratique cette problématique est gérée depuis (très) longtemps par les framework ou bibliothèques qui te mâchent le travail et t'évitent normalement (même si mongo est dans le cas présent un parfait contre-exemple) de faire trop facilement de grosses conneries.
Le truc du bas niveau, franchement, c'est probablement un faux problème. Parfois le bas niveau c'est utilisé pour pallier aux faiblesses du haut niveau mal conçu … Les perfs, si c'est une abstraction au niveau du langage, il n'y a pas de raison qu'il y ait une pénalisation par rapport aux abstractions codées dans des libs qui sont la pratique la plus courante, au contraire même, donc non je ne pense pas que ce soit un argument non plus.
Que ça soit au niveau du langage ou non ce qui va être envoyé au serveur de base de données c'est une chaîne de caractère contenant une requête. La conversion au niveau du langage n'étant pas magique elle a forcément un coût comme toute autre abstraction.
Je ne suis pas un dinosaure comme tu semble le sous entendre, notre système actuel est tout aussi élégant: on gère des des collections, des propriétés, des graphes et différents types de données directement dans le code et cela sans même écrire une seule ligne de SQL.
Créer une propriété ou une collection d'objets stocké en base ne prend qu'une seule ligne de PHP.
On peut le faire car on gère finement la construction de requêtes complexes, parfois récursives ou composées de sous requêtes dans notre couche abstraction. Je ne vois pas l'intérêt d'ajouter une couche d'abstraction à une autre.
Tout cela permet aussi de fortement limiter le nombre de requêtes effectuées, on utilise pour cela un système de cache complexe caché dans cette couche d'abstraction.
Encore une fois, PHP, sans un bon framework, n'offre rien pour gérer de nombreux aspects du développement web : la construction d'interfaces web / templates, les formulaires, la communication ajax/comet, les sessions, l'output buffering, le un système de routage d'url n'existent pas ou ne sont pas évident à gérer sans une (très) bonne connaissance du langage et demandent effectivement une bonne couche d'abstraction pour êtres pratiques à utiliser au quotidien. La base de données n'est qu'un petit aspect du problème et il existe de nombreuses réponses possibles.
Est ce que php est un mauvais language pour autant ? Non car ce n'est tout simplement pas sa vocation : ce n'est pas un environnement de RAD. Les couches supérieures sont maintenues par d'autres projets et offrent du choix.
Si PHP est aussi populaire aujourd'hui c'est aussi certainement car il en existe beaucoup de ces systèmes avec des approches très différentes.
et en attendant on a toujours pas réglé le problème de base : le langage rend trop simple l'écriture de code vulnérable et oblige à des compétences pour écrire du code non vulnérable.
Les compétences seront toujours nécessaires quel que soit le langage, la sécurisation d'un code n'est pas magique.
Ajouter des couches permet de ne pas gérer le problème toi même, ils ne cessent pas d'exister pour autant.
Que cette couche soit directement dans le langage ou dans le framework que tu as choisis ne change pas grand chose au final.
Pour utiliser le système de construction de requête que tu préfères, voir de le construire toi même.
Exécuter une requête par une fonction en lui passant en string la query çà reste une base. C'est peut être trop "bas niveau" pour certains mais complexifier à ce niveau oui c'est pour moi une erreur dans un langage tel que PHP ou de toute manière le langage seul ne permettra pas de gérer un projet sans une bonne base de code et d'outils. En tout cas pas sans exploser les délais. Le tout est de pouvoir choisir ses outils.
Dans ma société on utilise un système de mapping entre les objets et la base de données, il est rare que l'on ait à écrire une requête manuellement en développement et si c'est le cas une classe d'abstraction gère l'aspect sécurité.
Ajouter encore une couche d'abstraction complexe dans le langage n'aurait pas d’intérêt dans ce cas et serait certainement néfaste pour les performances.
Proposer un autre système, en complément du bas niveau, dans le langage ça serait sympa, c'est assez élégant ce qui se fait dans le doc que tu as posté, mais dans ce cas la problématique d'être au courant que ça existe est aussi présente.
En attendant des systèmes d'abstractions pour PHP qui fonctionnent y'en a à la pelle.
D'où le problème "philosophique" pour un mode de fonctionnement en typage faible.
Du coup au lieux de concaténer des strings et de les passer à une fonction qui va l'interpréter comme du SQL, si on a tout simplement pas de fonction qui lancent des requête qui ne font pas d'échappement systématique de toutes les strings raw avant de basculer dans le type "fragment de SQL", par exemple, on a déjà probablement moins de problème vu qu'il faut que le dev s'embête beaucoup plus pour aller se tirer une balle dans le pied …
Implémenter ça dans une couche d'abstraction / un framework en utilisant des objets c'est tout à fait possible.
Mais en l’implémentant au niveau des fonctions SQL de PHP on risque de s'embêter beaucoup plus pour faire des choses simples / voulues aussi, pas que pour la balle dans le pied :).
La syntaxe pour construire des tableaux dans la query string n'est pas propre à PHP, cela fonctionne aussi en Java et dans d'autres langages. En java le typage obligatoire fera qu'il n'y aura pas de surprises sur ce qui sera récupéré.
L'utilisation du typage fort en PHP étant maintenant possible, le même principe peut être appliqué.
Trans-typer en fonctionnant en typage faible pour obtenir le type attendu dans le cadre d'une utilisation normale - un tableau dans le cas d'une liste de sélection à choix multiple par exemple - irait à l'encontre de la logique de typage faible, en tout cas j'y vois tout de même une certaine logique et une fonctionnalité pratique dans la plupart des cas.
La sécurisation des entrées va de toute manière bien au delà de ce problème de typage qui n'est qu'une petite facette des problématiques à gérer, une string n'est pas moins dangereuse si elle est utilisée dans une requête sans être vérifiée.
Le typage fort te permet de te passer de la première vérification (la variable est forcément du bon type).
La prise en compte des tableaux étant une fonctionnalité de mongo qui permet de construire des requêtes elle n'a pas a être accessible depuis les données postés dans un formulaire donc c'est effectivement un problème de type dans le sens où le type array ne doit pas être passé à mongo depuis un formulaire. D'ailleurs à part pour les Select permettant le choix multiple on a normalement très rarement un tableau en entrée de formulaire, donc les interdire par défaut n'est pas une mauvaise idée.
Alors si c'est bien l'objet de la question, non il n'est pas possible de typer directement le contenu de $_GET / $_POST en PHP.
Du coup même typée statiquement la variable password de l'exemple précédent fait qu'il faudra gérer l'exception TypeError qui sera levée lors de l'affectation. Bon il n'y aura déjà plus de faille de sécurité, juste un script qui plante, c'est déjà mieux.
Par contre écrire une fonction d'abstraction pour accéder aux données de get/post est une bonne pratique et une pratique courante (si vous utilisez netbeans ide par exemple, vous aurez une astuce vous disant qu'accéder directement à ces variables c'est le MAL(tm), à raison).
Si cette fonction est présente l'utiliser pour effectuer un trans-typage automatique est assez trivial.
va transformer le type tableau non attendu en une chaîne de caractères "inoffensive" (je ne parle pas des failles d'injections / de safe escape dans ce cas) contenant "Array".
[^] # Re: Est ce bien utile ? :-)
Posté par Chris K. . En réponse au journal tnt passage au H264. Évalué à 3.
Hum le gros carré ou il y a marqué direct avec les liens pour les différentes chaines du groupe est pas assez gros ?
Ou il y a une histoire de droits de diffusion spécifique aux 6 nations ? Car le direct fonctionne très bien actuellement.
[^] # Re: Souveraineté numérique ?
Posté par Chris K. . En réponse à la dépêche Un système d’exploitation français pour la souveraineté numérique. Évalué à 5. Dernière modification le 09 février 2016 à 14:59.
Je pense plutôt pour ma part que c'est la construction européenne elle même qui fait que c'est un échec : les états européens sont bien trop occupés à chercher à gérer leurs différences (fiscales, sociales, législatives, …) avec les autres membres de cet espace économique pour arriver à défendre leurs intérêts communs au niveau global, face aux autres géants que sont les USA et face aux nouvelles puissances économiques BRICS, car la construction de cet espace économique s'est faite dans le désordre et la précipitation.
Sinon, si les gens ne se reconnaissent pas là dedans c'est surtout et avant tout à cause de l'absence de représentants de l’exécutif (commission européenne) élus sur un modèle démocratique direct.
On a actuellement une belle machine à perdre sans réel parti ou responsables politiques identifiés par la population, sans interlocuteurs à l'international, sans réels projets pour le continent en dehors de ceux de l'OMC et des lobbys qui remplissent les couloirs des institutions. Et surtout sans alternance politique possible.
Bien qu'il doit encore être possible de faire autre chose que de devenir une simple annexe politique des USA en inventant un nouveau modèle démocratique européen, je suis moi aussi assez pessimiste quant à l'avenir de cette union et à sa capacité même à défendre ses propres intérêts.
[^] # Re: Est ce bien utile ? :-)
Posté par Chris K. . En réponse au journal tnt passage au H264. Évalué à 3. Dernière modification le 09 février 2016 à 12:43.
Ils ne le diffusent pas sur pluzz ? http://pluzz.francetv.fr/ ?
# Accès utilisateur
Posté par Chris K. . En réponse au message Écriture/Lecture sur DDE format NTFS. Évalué à 2. Dernière modification le 09 février 2016 à 12:06.
Je ne suis pas sûr que ton problème vient forcément du driver utilisé pour monter le disque.
Pourrais tu nous donner la sortie de la commande mount (sans arguments/options) pour voir si il est effectivement monté en lecture seule ou si c'est simplement un problème de droits d'accès pour ton utilisateur normal (non root).
[^] # Re: Restons raisonnable !
Posté par Chris K. . En réponse au message Comment confier la maintenance de son serveur sans se faire voler ?. Évalué à 3.
Malheureusement pas d'administration système sans droits root.
Quand on exerce ce genre de métiers on se doit tout de même d'avoir une certaine éthique. Un prestataire qui blouserai ses clients - de plus en enfreignant clairement la loi - va très vite s'attirer d'énormes ennuis et disparaître.
La vraie chose dont tu dois te méfier c'est la compétence réelle du presta et sa tarification. Là il est possible et facile de se faire voler en toute légalité.
# MAJ
Posté par Chris K. . En réponse au message connecter un iphone 4 s . Évalué à 4.
Sur un système récent et depuis un bon moment maintenant les téléphones de la pomme sont reconnus comme une clé USB.
Mais ton téléphone étant sortit plusieurs mois après ta distribution, pas sur qu'elle le supporte correctement. Une mise à jour du système - qui date quand même de près de 6 ans - devrait te permettre de régler le problème.
# Salut l'artiste
Posté par Chris K. . En réponse au journal Paul Kantner bronsonisé. Évalué à 7. Dernière modification le 30 janvier 2016 à 15:07.
Il faut dire que c'était un maître, Kantner.
[^] # Re: Jamais testé mais intéressant
Posté par Chris K. . En réponse au message [RESOLU] Problèmes avec les partitions. Évalué à 2.
Oui c'est possible qu'il y ait quelques manipulations à faire pour remettre grub d'aplomb.
Pour windows vu qu'il y a grub qui va chainloader entre ça peut peut être passer.
# Jamais testé mais intéressant
Posté par Chris K. . En réponse au message [RESOLU] Problèmes avec les partitions. Évalué à 3. Dernière modification le 29 janvier 2016 à 13:00.
ATTENTION : je n'ai jamais testé cette méthode, donc si tu veux tenter il faudra faire une sauvegarde complète du disque avant.
Il s'agit de convertir ton disque au format GPT, ce qui supprimera aussi la limite de 4 partitions primaires (128 partitions possibles sur GPT).
L'utilitaire gdisk a une option pour cela :
http://www.rodsbooks.com/gdisk/mbr2gpt.html
Reste aussi à voir si les chargeurs de démarrage retrouvent leurs petits.
Donc à tester seulement si tu as du temps.
[^] # Re: arnaque énorme
Posté par Chris K. . En réponse au journal Priorité aux logiciels libres - Lettre ouverte à Axelle Lemaire. Évalué à 4.
L'état est dans ce cas aussi un très gros client avec d'énormes moyens concentrés aujourd'hui vers ces sociétés. Cela devrait lui donner le poids nécessaire pour avoir la main sur les logiciels qu'il utilise si seulement il le décidait que ce soit avec ou sans ses partenaires actuels.
Si le problème était seulement économique ce n'en serait pas un. La sécurité nationale, les écoutes, la capacité du pays d'avoir une indépendance par rapport aux géants américains… tout cela est lié.
La forme que peut prendre une guerre moderne devrait un peu plus nous inquiéter sur toutes ces questions.
Malheureusement à force de manquer de cojones, comme tu le dit très bien, j'ai l'impression qu'on a abandonné une idée qui a fait la force ce pays et a permis de faire travailler pendant des décennies ses cerveaux sur des technologies de pointe, celle d'une certaine forme d'indépendance.
[^] # Re: Hum
Posté par Chris K. . En réponse au journal Sortir de l'état d'urgence. Évalué à 2. Dernière modification le 28 janvier 2016 à 12:14.
Il y a tout de même différentes catégories de couteaux… poignarder quelqu'un avec le couteau à pain c'est pas super facile. Couper le pain avec un poignard non plus ^^.
[^] # Re: Ouuuuupssss
Posté par Chris K. . En réponse au message Permissions. Évalué à 3. Dernière modification le 26 janvier 2016 à 15:19.
Non en effet c'est pas très propre. Si il y a d'autres services qui fonctionnent encore ça pourrait même être pire.
Sous Debian ou une dérivée comme Ubuntu tu peux demander la réinstallation de tous les paquets ce qui remettra les bons droits sur le système.
Pour le serveur ts, si il est installé par un package cela réglera le problème. Sinon il faudra faire un chown manuellement en se limitant cette fois à son emplacement d'installation.
[^] # Re: Ardour
Posté par Chris K. . En réponse à la dépêche Sortie de LibraZiK 1.0 : Premier pas (20160107). Évalué à 4. Dernière modification le 22 janvier 2016 à 13:00.
Juste pour information tu as un bouton en dessous des commentaires qui te permet de répondre aux commentaires dans le fil, c'est plus lisible et les personnes auxquelles tu réponds reçoivent une notification ;)
Sinon beau projet je vais jeter un œil !
[^] # Re: Typage strict
Posté par Chris K. . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 2.
Non mais c'est une blague… Je te pose des questions tout de même assez précises pour avoir une idée dont devrait fonctionner ton système merveilleux et tu te contente de me balancer des liens sur le fonctionnement de tex.
Si pour toi il est si facilement possible de faire mieux que ce qui existe, c'est que tu as bien une idée sur la façon dont l'abstraction devrait fonctionner dans le langage en dehors du type fragment sql / chaine non sécurisée quand les données proviennent de l'entrée utilisateur dont tu nous as parlé non ?
[^] # Re: Typage strict
Posté par Chris K. . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 2.
Puissance limitée tout de même : LINQ ne gère pas, par exemple, les requêtes récursives en SQL. Donc il va falloir contourner un problème qui n'a aucune raison d'exister si par malheur tu en as besoin. Pour cela et pour les raisons évoquées précédemment ce n'est certainement pas la solution universelle.
Euh oui enfin c'est tout de même toi qui est venu avec LINQ pour exemple et qui propose justement de se débarrasser complètement de la query string SQL pour régler ce problème.
Le problème est bien là : entre ajouter une petite fonction native gérant un sprintf et du safe_escape sur des données typées pour finalement les insérer là où tu veux dans une query string et une intégration au langage comme LINQ il y a un monde et il n'est pas évident de savoir où tu mets le curseur pour définir ce fameux système de sécurisation des requêtes universel qui conviendra à tous les usages.
Mes propos concernaient là encore les manques de LINQ, maintenant tu viens me parler de Tex…
De quelle façon tu comptes te servir concrètement d'un tel système pour gérer la problématique évoquée ?
Je ne suis d'ailleurs pas non plus convaincu, à la base, qu'il soit si pertinent de vouloir mixer deux choses très différentes : un langage de programmation et un langage de requête dans une syntaxe commune qui n'exprime pas clairement ce qui sera envoyé au serveur.
[^] # Re: Typage strict
Posté par Chris K. . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 3.
Ah oui point très important sur lequel je n'ai pas répondu pour terminer :
La diversité est une force et non une faiblesse, tout comme dans le LL en général.
Système élégant et puissant ne signifie pas pour autant réponse universelle, surtout dans le cadre d'une problématique aussi complexe que la gestion de la communication avec une base de données et plus spécialement dans le cas de SQL qui possède de nombreuses variantes.
LINQ, par exemple peut poser de nombreux problèmes notamment pour optimiser une requête lorsque tu n'as pas réellement la main dessus.
On déplace la complexité à un autre niveau sans pour autant avoir un contrôle direct dessus. En tout cas bien moins facilement qu'avec une bibliothèque écrite dans le même langage, qui peut être propre au projet, et facilement modifiable à souhait.
Quand on dépend directement de l'interpréteur, c'est tout de même beaucoup moins souple si l'on souhaite étendre le système ou faire la moindre adaptation sur son comportement.
[^] # Re: Typage strict
Posté par Chris K. . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 2.
Oui, on est pas d'accord, ce n'est pas grave. Après je te réponds poliment, en argumentant. Si cela t'embêtes effectivement mieux vaut arrêter.
Tu regardes cela d'un point de vue trop théorique selon moi, comme si l'on construisait aujourd'hui une application complète en partant avec comme seule base ce qui est nativement dans le langage.
Dans la pratique cette problématique est gérée depuis (très) longtemps par les framework ou bibliothèques qui te mâchent le travail et t'évitent normalement (même si mongo est dans le cas présent un parfait contre-exemple) de faire trop facilement de grosses conneries.
[^] # Re: Typage strict
Posté par Chris K. . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 2. Dernière modification le 20 décembre 2015 à 02:42.
Que ça soit au niveau du langage ou non ce qui va être envoyé au serveur de base de données c'est une chaîne de caractère contenant une requête. La conversion au niveau du langage n'étant pas magique elle a forcément un coût comme toute autre abstraction.
Je ne suis pas un dinosaure comme tu semble le sous entendre, notre système actuel est tout aussi élégant: on gère des des collections, des propriétés, des graphes et différents types de données directement dans le code et cela sans même écrire une seule ligne de SQL.
Créer une propriété ou une collection d'objets stocké en base ne prend qu'une seule ligne de PHP.
On peut le faire car on gère finement la construction de requêtes complexes, parfois récursives ou composées de sous requêtes dans notre couche abstraction. Je ne vois pas l'intérêt d'ajouter une couche d'abstraction à une autre.
Tout cela permet aussi de fortement limiter le nombre de requêtes effectuées, on utilise pour cela un système de cache complexe caché dans cette couche d'abstraction.
Encore une fois, PHP, sans un bon framework, n'offre rien pour gérer de nombreux aspects du développement web : la construction d'interfaces web / templates, les formulaires, la communication ajax/comet, les sessions, l'output buffering, le un système de routage d'url n'existent pas ou ne sont pas évident à gérer sans une (très) bonne connaissance du langage et demandent effectivement une bonne couche d'abstraction pour êtres pratiques à utiliser au quotidien. La base de données n'est qu'un petit aspect du problème et il existe de nombreuses réponses possibles.
Est ce que php est un mauvais language pour autant ? Non car ce n'est tout simplement pas sa vocation : ce n'est pas un environnement de RAD. Les couches supérieures sont maintenues par d'autres projets et offrent du choix.
Si PHP est aussi populaire aujourd'hui c'est aussi certainement car il en existe beaucoup de ces systèmes avec des approches très différentes.
Les compétences seront toujours nécessaires quel que soit le langage, la sécurisation d'un code n'est pas magique.
Ajouter des couches permet de ne pas gérer le problème toi même, ils ne cessent pas d'exister pour autant.
Que cette couche soit directement dans le langage ou dans le framework que tu as choisis ne change pas grand chose au final.
[^] # Re: pour quel usage
Posté par Chris K. . En réponse au message Cherche références de cartes sons PCIe fonctionnant out of the box. Évalué à 3. Dernière modification le 19 décembre 2015 à 09:24.
Le problème reste le même qu'avec une carte pcie : il faut un chip supporté.
Dans le pcie pas cher tu peux regarder du coté des cartes à base de chip CMedia (CMXXXX), c'est facilement trouvable à moins de 20€.
[^] # Re: Typage strict
Posté par Chris K. . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 2. Dernière modification le 18 décembre 2015 à 19:44.
Cela permet surtout d'avoir le choix.
Pour utiliser le système de construction de requête que tu préfères, voir de le construire toi même.
Exécuter une requête par une fonction en lui passant en string la query çà reste une base. C'est peut être trop "bas niveau" pour certains mais complexifier à ce niveau oui c'est pour moi une erreur dans un langage tel que PHP ou de toute manière le langage seul ne permettra pas de gérer un projet sans une bonne base de code et d'outils. En tout cas pas sans exploser les délais. Le tout est de pouvoir choisir ses outils.
Dans ma société on utilise un système de mapping entre les objets et la base de données, il est rare que l'on ait à écrire une requête manuellement en développement et si c'est le cas une classe d'abstraction gère l'aspect sécurité.
Ajouter encore une couche d'abstraction complexe dans le langage n'aurait pas d’intérêt dans ce cas et serait certainement néfaste pour les performances.
Proposer un autre système, en complément du bas niveau, dans le langage ça serait sympa, c'est assez élégant ce qui se fait dans le doc que tu as posté, mais dans ce cas la problématique d'être au courant que ça existe est aussi présente.
En attendant des systèmes d'abstractions pour PHP qui fonctionnent y'en a à la pelle.
[^] # Re: Typage strict
Posté par Chris K. . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 2. Dernière modification le 18 décembre 2015 à 11:05.
D'où le problème "philosophique" pour un mode de fonctionnement en typage faible.
Implémenter ça dans une couche d'abstraction / un framework en utilisant des objets c'est tout à fait possible.
Mais en l’implémentant au niveau des fonctions SQL de PHP on risque de s'embêter beaucoup plus pour faire des choses simples / voulues aussi, pas que pour la balle dans le pied :).
[^] # Re: Typage strict
Posté par Chris K. . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 2.
La syntaxe pour construire des tableaux dans la query string n'est pas propre à PHP, cela fonctionne aussi en Java et dans d'autres langages. En java le typage obligatoire fera qu'il n'y aura pas de surprises sur ce qui sera récupéré.
L'utilisation du typage fort en PHP étant maintenant possible, le même principe peut être appliqué.
Trans-typer en fonctionnant en typage faible pour obtenir le type attendu dans le cadre d'une utilisation normale - un tableau dans le cas d'une liste de sélection à choix multiple par exemple - irait à l'encontre de la logique de typage faible, en tout cas j'y vois tout de même une certaine logique et une fonctionnalité pratique dans la plupart des cas.
La sécurisation des entrées va de toute manière bien au delà de ce problème de typage qui n'est qu'une petite facette des problématiques à gérer, une string n'est pas moins dangereuse si elle est utilisée dans une requête sans être vérifiée.
[^] # Re: Typage strict
Posté par Chris K. . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 3. Dernière modification le 16 décembre 2015 à 15:35.
La prise en compte des tableaux étant une fonctionnalité de mongo qui permet de construire des requêtes elle n'a pas a être accessible depuis les données postés dans un formulaire donc c'est effectivement un problème de type dans le sens où le type array ne doit pas être passé à mongo depuis un formulaire. D'ailleurs à part pour les Select permettant le choix multiple on a normalement très rarement un tableau en entrée de formulaire, donc les interdire par défaut n'est pas une mauvaise idée.
Alors si c'est bien l'objet de la question, non il n'est pas possible de typer directement le contenu de $_GET / $_POST en PHP.
Du coup même typée statiquement la variable password de l'exemple précédent fait qu'il faudra gérer l'exception TypeError qui sera levée lors de l'affectation. Bon il n'y aura déjà plus de faille de sécurité, juste un script qui plante, c'est déjà mieux.
Par contre écrire une fonction d'abstraction pour accéder aux données de get/post est une bonne pratique et une pratique courante (si vous utilisez netbeans ide par exemple, vous aurez une astuce vous disant qu'accéder directement à ces variables c'est le MAL(tm), à raison).
Si cette fonction est présente l'utiliser pour effectuer un trans-typage automatique est assez trivial.
[^] # Re: Typage strict
Posté par Chris K. . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 4. Dernière modification le 16 décembre 2015 à 10:27.
PHP permet tout de même de faire du trans-typage (http://php.net/manual/fr/language.types.type-juggling.php#language.types.typecasting), dans le cas de la faille en question :
va transformer le type tableau non attendu en une chaîne de caractères "inoffensive" (je ne parle pas des failles d'injections / de safe escape dans ce cas) contenant "Array".
[^] # Re: amdgpu / fglrx
Posté par Chris K. . En réponse au message mauvaise performance CG amd radeon R7 250e. Évalué à 2. Dernière modification le 15 décembre 2015 à 13:22.
Mieux vaut blacklister amdgpu et utiliser fglrx si il veut jouer en 3d (pour le moment).
Il faudrait déjà vérifier que le module est bien chargé actuellement et que c'est bien ça le soucis.
Matteli, que donne un " lspci -vvv | grep amdgpu " ?