Justement je viens vers vous car je pense qu’il y a moyen de faire en sorte d’avoir la Securité ajouter a la 4.2 et l’avantage que donne Jeedom avec des plugin tiers reste facile d’accès.
Loin de moi de demander de supprimer toute tes modification, c’est un gros plus pour Jeedom. Mais je pense que moyennant un peux de temps pour développer une interface et quelque fonction il y a moyen de géré dynamiquement ce header en particulier. Cela permettrait de garder la sécurité et de pouvoir laisser une possibilité d’utiliser des lib externe sans couper toute la sécurité.
Ps : Je pense que la sécurité est important et je trouve sa super que Jeedom s’y interesse
Bonjour,
Je viens de faire un test sur gsl en bêta en ajoutant un proxy php.
Leaflet dans mon cas, passe l’URL en local au proxy qui va chercher la tuile.
Le proxy fait quelques vérifications sur les urls
Le périphérique est créé à partir des données récupérées via l’API Tuya, dont l’image.
Maintenant que faire avec cette image pour qu’elle s’affiche dans le plugin.
Le proxy Php s’est bien, on en parlait déjà mais par contre, et je n’ai pas regardé le code encore donc je ne sais pas ce qui est fait, il ne faut certainement pas un proxy qui accepte n’importe quelle url http sinon toute la secu de jeedom apportée par les CSP est parterre !
Il ne faut passer qu’un morceau du path, le valider/nettoyer au cas où quelque chose y a été injecté et reconstruire l’url en Php en rajoutant et donc en forçant le domaine et le protocol;
Dans le cas contraire il suffira au code injecté de passer par ce proxy pour downloader ce qu’il veut sur le poste client, ça ou le télécharger en directe c’est pareil.
On est dans l’exemple parfait au « trop » de sécurité (celle qui casse les fonctionnalités), tue la sécurité voulue au départ.
Il faut un mécanisme par lequel des sites de « confiances » peuvent être rajouté à la liste, idéalement à la volée et seulement lors de l’affichage de certaines pages (pour réduire la surface) donc concrètement uniquement lorsque le widget qui en a besoin s’affiche par exemple ou uniquement sur la page de config qui en a besoin.
Pour me répéter encore autrement: s’il n’y a pas de solution propre offerte pour accepter certains sites de confiances dans certains cas où c’est nécessaire, une solution de contournement sera trouvée par un dev et cela créera une brèche (voir un boulevard); et à ce moment autant ne rien mettre au départ, ça fait moins de maintenance pour jeedom et ça ne donne pas une fausse impression de sécurité.
Ce proxy devrait être intégré dans le core, ainsi le cleaning est fait de façon centralisée, ça évitera que chacun redeveloppe (avec des erreurs) sa solution et les domaines cibles autorisés devraient être déclarés par les plugins dans leur config par exemple, le proxy vérifiera lors de la requête client que le domaine se trouve dans la liste du plug-in pour lequel la requête est faite.
Et autoriser le téléchargement d’une map depuis Google maps ce n’est pas un trou de sécurité.
Je me permets de revenir sur ce sujet pour connaitre les bonnes pratiques à avoir dans le cadre des requêtes ajax.
J’ai en effet procédé à qq modifications dans mon plugin Verisure en vue d’être 100% compatible avec la v4.2. Notamment dans le widget où, pour afficher les informations des modules existants (température, état, humidité,…), je vais les chercher dans un fichier json régulièrement mis à jour.
J’ai dans un premier temps utilisé la méthode avec le fichier downloadFile.php et cela fonctionne bien mais comme certains de mes utilisateurs n’ont pas que des comptes « admin », je suis passé par une requête ajax pour palier à ce cas.
Et c’est là que ma question arrive
Dans mon fichier verisure.ajax.php j’ai :
if (!isConnect('admin'))
throw new Exception(__('401 - Accès non autorisé', __FILE__));
}
J’avais procédé ainsi puisque l’action de création d’un équipement ne doit être fait que par un admin.
Masi du coup en rajoutant mon action pour la lecture du json, celle-ci doit être accessible à tout utilisateur connecté donc avec :
if (!isConnect())
throw new Exception(__('401 - Accès non autorisé', __FILE__));
}
Quelle est donc la meilleure façon de faire pour gérer ses 2 autorisations ? 2 fichiers xxxx.ajax.php ?
Avec chacun son niveau d’autorisation ? Ou un seul fichier mais dans ce cas comment gérer ces 2 niveaux d’autorisation ?
C’est toi qui voit j’ai envie de dire
Tant que tu t’assures que les actions admin sont réservée aux admins, je pense pas qu’il y ait un choix meilleur que l’autre.
J’ai un plug-in ou j’ai un fichier, je test la connexion (sans admin) pour faire les actions non-admin puis je test le profil admin avant de faire les actions admins mais 2 fichiers ça me semble valide aussi.
