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".
Heureusement les register_globals et magic quotes c'est plus possible, même avec PHP, depuis la sortie de la 5.4 en 2012.
Maintenant en effet c’était un gros piège pourri et ça aurait dû dégager bien avant vu que de toute manière les gens correctement informés ne l'utilisaient plus depuis (très) longtemps.
Une bonne règle à retenir est de ne surtout jamais faire confiance aux entrées fournies par le navigateur sans avoir vérifié qu'elle soient bien conformes à ce que l'on attend.
Amdgpu est un module noyau "natif" il est lié directement à l'installation du noyau linux assez récent (c'est apparu dans le 4.2 il me semble) et non à un package tiers.
xserver-xorg-video-amdgpu fournit ce qu'il faut à Xorg pour prendre en charge ce module, mais pas le module.
Le module fglrx est lui fourni par l'installation du driver proprio.
En fait je ne suis pas certain que la 250 soit concernée par amdgpu.
Sur Ubuntu 15.10, la dernière version des libs mesa / gallium et tout le toutim, une r9 385 (reconnue comme 380 par le driver fglrx, elle embarque le tout dernier gpu de la marque) le nouveau driver amdgpu "fonctionne", c'est a dire que Xorg démarre. Par contre je n'ai pas réussi a faire fonctionner l’accélération 3D, que le driver proprio soit installé ou non. Lorsque le CCC est installé la carte est marquée comme non reconnue avec le module amdgpu.
Bref pour amdgpu il faut encore attendre que le travail d'intégration se fasse au niveau des distributions (voir du driver proprio amd) et cela quelle que soit la carte c'est encore un peu frais.
Par contre en attendant elles sont supportées par fglrx sans soucis.
J'ai eu le même soucis récemment avec une 380 qui n'était pas reconnue dans le catalyst control center.
A vérifier de ton coté mais pour ma part c'était lié au chargement du nouveau driver amdgpu à la place de fglrx.
Si c'est le cas, pour utiliser le pilote proprio de la carte il va falloir blacklister le pilote amdgpu au démarrage (sudo echo "blacklist amdgpu" > /etc/modprobe.d/amdgpu.conf && sudo update-initramfs -u") pour ne pas qu'il se charge à la place du driver proprio catalyst fglrx puis redémarrage.
Je pensais à la base le contraire mais visiblement pour le moment avec le driver proprio il faut encore utiliser le module fglrx sur ces cartes pour avoir une accélération graphique qui fonctionne.
Aller chercher les dépendances c'est justement ce que le
sudo apt-get -f install
va faire.
Mais gdebi ou le software center ont le mérite d'êtres graphiques donc peut être aussi un peu plus user friendly / clair pour ceux qui ne sont pas habitués à la ligne de commande.
Pour sshfs je ne sais pas exactement d'où vient le problème.
Par contre pour ma part je configure des acls sur les dossiers pour éviter que des droits sautent sur les serveurs web.
Un bon coup de setfacl avec les bons droits pour l'écriture et un script en cron daily avec chmod 550 + chown sur l'utilisateur du serveur web pour avoir des droits posix inoffensifs devraient faire le boulot. N'oublies simplement pas de laisser des droits au serveur web dans les dossiers où il doit pouvoir uploader / déplacer des fichiers.
Ton problème d'authentification peut être contourné relativement facilement.
L'authentification par mot de passe / http n'est pas conservée par iOS c'est surtout là que se situe ton problème. Maintenant si au lieu d'utiliser cette authentification par mot de passe / HTTP tu utilises un petit formulaire - avec le langage de ton choix - tu peux enregistrer un cookie qui pourra servir d'authentification pour l'accès à la vidéo et le problème iOS sera réglé ;)
[^] # 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 " ?
[^] # 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 15 décembre 2015 à 13:08.
Heureusement les register_globals et magic quotes c'est plus possible, même avec PHP, depuis la sortie de la 5.4 en 2012.
Maintenant en effet c’était un gros piège pourri et ça aurait dû dégager bien avant vu que de toute manière les gens correctement informés ne l'utilisaient plus depuis (très) longtemps.
[^] # 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.
Magnifique en effet .
Une bonne règle à retenir est de ne surtout jamais faire confiance aux entrées fournies par le navigateur sans avoir vérifié qu'elle soient bien conformes à ce que l'on attend.
[^] # 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 à 10:55.
Amdgpu est un module noyau "natif" il est lié directement à l'installation du noyau linux assez récent (c'est apparu dans le 4.2 il me semble) et non à un package tiers.
xserver-xorg-video-amdgpu fournit ce qu'il faut à Xorg pour prendre en charge ce module, mais pas le module.
Le module fglrx est lui fourni par l'installation du driver proprio.
[^] # 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 13 décembre 2015 à 13:13.
En fait je ne suis pas certain que la 250 soit concernée par amdgpu.
Sur Ubuntu 15.10, la dernière version des libs mesa / gallium et tout le toutim, une r9 385 (reconnue comme 380 par le driver fglrx, elle embarque le tout dernier gpu de la marque) le nouveau driver amdgpu "fonctionne", c'est a dire que Xorg démarre. Par contre je n'ai pas réussi a faire fonctionner l’accélération 3D, que le driver proprio soit installé ou non. Lorsque le CCC est installé la carte est marquée comme non reconnue avec le module amdgpu.
Bref pour amdgpu il faut encore attendre que le travail d'intégration se fasse au niveau des distributions (voir du driver proprio amd) et cela quelle que soit la carte c'est encore un peu frais.
Par contre en attendant elles sont supportées par fglrx sans soucis.
# amdgpu / fglrx
Posté par Chris K. . En réponse au message mauvaise performance CG amd radeon R7 250e. Évalué à 3. Dernière modification le 13 décembre 2015 à 12:25.
J'ai eu le même soucis récemment avec une 380 qui n'était pas reconnue dans le catalyst control center.
A vérifier de ton coté mais pour ma part c'était lié au chargement du nouveau driver amdgpu à la place de fglrx.
Si c'est le cas, pour utiliser le pilote proprio de la carte il va falloir blacklister le pilote amdgpu au démarrage (sudo echo "blacklist amdgpu" > /etc/modprobe.d/amdgpu.conf && sudo update-initramfs -u") pour ne pas qu'il se charge à la place du driver proprio catalyst fglrx puis redémarrage.
Je pensais à la base le contraire mais visiblement pour le moment avec le driver proprio il faut encore utiliser le module fglrx sur ces cartes pour avoir une accélération graphique qui fonctionne.
# Snapshots
Posté par Chris K. . En réponse au message Sauvegarder son système dans une virtual box. Évalué à 4.
Tu peux utiliser les snapshots :
http://www.it-connect.fr/la-gestion-des-snapshots-avec-virtualbox/
[^] # Re: facile a comprendre pourtant
Posté par Chris K. . En réponse au message Gestionnaire de fichier qt/kde utilisant gvfs. Évalué à 3.
J'ai très bien compris l'origine des deux systèmes mais je ne compte pas pour autant changer de DE car le reste me va très bien.
Phonon sait bien utiliser gstreamer en backend par exemple et je ne vois pas où est le problème.
Si les développeurs de KDE tiennent à réinventer la roue et même si elle est carrée dans le cas de kio, ils font bien ce qu'ils veulent.
Nautilus sous kde marche très bien. Le seul bémol est au niveau de l'intégration "esthétique". Sur le coté fonctionnel il n'y a aucun soucis.
Après si y'a a pas… ben y'a pas c'est pas plus grave, je préfère toujours un outil moche/mal intégré qui fonctionne à un bel outil qui ne sert à rien.
# Driver
Posté par Chris K. . En réponse au message Problème installation carte wifi usb. Évalué à 3. Dernière modification le 26 octobre 2015 à 15:03.
Ton chip est pris en charge par le driver rt2800usb qui est dans debian, donc très certainement dans kali.
Par contre il a besoin du firmware propriétaire pour fonctionner.
Tu dois avoir un paquet firmware-ralink dans les dépôts non-free. Sinon tu peux toujours utiliser ceux de debian.
Chris.
[^] # Re: Suggestions
Posté par Chris K. . En réponse au message problème wifi. Évalué à 2. Dernière modification le 17 septembre 2015 à 23:45.
As tu installé le package linux-firmware-nonfree ?
Certains chipset wifi font juste semblant de fonctionner sans leur firmware propriétaire.
# Onlyoffice ou autre
Posté par Chris K. . En réponse au message CMS avec gestion document, tableau, rapport qui génère des doc (doc,odt, pdf, ...). Évalué à 3.
On en parlait ici :
https://linuxfr.org/news/collaborer-sur-vos-documents-a-l-aide-du-libre
Je pense que tu devrais le retrouver dans la liste ;)
[^] # Re: mint = ubuntu = debian
Posté par Chris K. . En réponse au message drivers pour imprimante canon ip7250. Évalué à 3. Dernière modification le 15 septembre 2015 à 14:18.
Si cela va fonctionner.
Aller chercher les dépendances c'est justement ce que le
va faire.
Mais gdebi ou le software center ont le mérite d'êtres graphiques donc peut être aussi un peu plus user friendly / clair pour ceux qui ne sont pas habitués à la ligne de commande.
# ACLs
Posté par Chris K. . En réponse au message Développement web, droits des fichiers, ssh, sshfs. Évalué à 3.
Pour sshfs je ne sais pas exactement d'où vient le problème.
Par contre pour ma part je configure des acls sur les dossiers pour éviter que des droits sautent sur les serveurs web.
Un bon coup de setfacl avec les bons droits pour l'écriture et un script en cron daily avec chmod 550 + chown sur l'utilisateur du serveur web pour avoir des droits posix inoffensifs devraient faire le boulot. N'oublies simplement pas de laisser des droits au serveur web dans les dossiers où il doit pouvoir uploader / déplacer des fichiers.
# Hey oui !
Posté par Chris K. . En réponse au journal Les brevets logiciels toujours interdits en France. Évalué à 5.
Je me rappelle de cette histoire j'avais fait un journal à ce propos à l'époque suspectant légèrement le coup fourré aux brevets logiciels.
http://linuxfr.org/users/chrisk/journaux/orange-attaque-free-pour-son-offre-de-replay
Mais je n'avais pas vu le jugement !
Merci pour l'info :)
# Auth HTTP
Posté par Chris K. . En réponse au journal Partager une vidéo privée : oui mais pas sur iOS. Évalué à 3.
Ton problème d'authentification peut être contourné relativement facilement.
L'authentification par mot de passe / http n'est pas conservée par iOS c'est surtout là que se situe ton problème. Maintenant si au lieu d'utiliser cette authentification par mot de passe / HTTP tu utilises un petit formulaire - avec le langage de ton choix - tu peux enregistrer un cookie qui pourra servir d'authentification pour l'accès à la vidéo et le problème iOS sera réglé ;)
Mes 2 cents. :)