Tout d'abord merci beaucoup pour tout le travail accompli sur le toolkit comme sur ces dépêches !
Merci de prendre le temps de s'y intéresser :-) !
J'ai quelques scripts python qui mériteraient bien une GUI et j'ai eu quelques soucis avec le TK de base fourni avec Python. J'étais sur le point de me lancer dans l'apprentissage de PyQT (et de QT par la même occasion) mais Atlas pourrait être une alternative moins coûteuse en temps d'apprentissage, avec la possibilité en plus de partager les applis plus facilement via les portails.
C'est précisément pour cela que ce toolkit a été conçu.
La question que je me pose est celle de la sécurité des applications mises à disposition sur ces portails, en particulier dans l'hypothèse où l'on utilise le portail public. L'applicatif est sensé gérer tout le côté authentification et gestion des accès, c'est bien ça ?
À l'image de la philosophie derrière UNIX, le toolkitAtlas ne fait qu'une seule chose, et tente de le faire le mieux possible, à savoir faciliter le développement d'une interface graphique. De ce fait, il n'offre aucune fonctionnalité en terme d'authentification, de gestion d'accès, voire relatifs aux bases de données, comme peuvent le proposer certains frameworks. D'où son appellation de toolkit, et non de framework.
Et comme il n'y a pas de serveur web, l'application a potentiellement accès à tout le disque dur sur lequel le programme tourne, ou en tout cas à toutes les données auxquelles a accès l'utilisateur actif ?
Ce n'est probablement pas évident au premier abord, mais l'ambition du toolkitAtlas n'est absolument pas d'être une alternative aux traditionnels frameworks de développement d"applications web, mais d'offrir un moyen simple et rapide d'ajouter une interface graphique à n'importe quel programme Python (dans le cas de la version Python du toolkit). Par conséquent, l'utilisation du toolkitAtlas dans un programme Python n'a pas plus d'influence sur ce à quoi ce programme Python a accès que s'il utilisait un toolkit comme PyQT. Le fait que l'utilisation du toolkitAtlas transforme de facto le programme en application web n'est, en quelque sorte, qu'un effet secondaire...
Dans ma compréhension, ce serait pour ça entre autre que l'accent est mis sur le prototypage d'applications plutôt que sur le développement d'applis web destinées à être mises en production (outre les limitations fonctionnelles potentielles par rapport à un client écrit entièrement en js) ? En gros il faut éviter de mettre des données de production dans de telles applis ?
Entre le programme et le serveur auquel il se connecte, la connexion n'est, à ce jour, pas chiffrée. Ce qui n'empêche pas le toolkitAtlas d'être utilisé en production, mais c'est clairement dans le cas où les données transitant entre l'application et le serveur ne sont pas sensibles, ou alors c'est avec mise en œuvre de la solution de contournement décrite plus bas.
Actuellement, le toolkit, quelque soit sa version, est très léger et autonome, sans dépendances. Toutes les version du toolkit, même les versions qui peuvent être installées avec un gestionnaire de paquets, peuvent être fournies sous forme d'archive auto-suffisante, ce qui facilite son utilisation notamment dans un cadre éducatif. Ajouter le chiffrement rendrait l'installation du toolkit beaucoup plus compliquée, sans compter le travail que cela représente en matière de développement, tant au niveau du toolkit proprement dit, vu sa disponibilité pour plusieurs langages, que du serveur auquel il se connecte.
Cela ne signifie pas que ce chiffrement ne sera jamais disponible, mais ce sera probablement sous forme d'extension, ou d'une version distincte, peut-être spécialement destinée à un usage professionnel, avec connexion à serveur dédié...
On peut actuellement contourner ce problème en installant le logiciel serveur (qui est diffusé sous licence libre) sur une machine sur laquelle on installerait également le programme Python. De ce fait, les échanges programme/serveur ne sortiraient pas de la machine et ne pourraient donc être que très difficilement interceptés.
Merci d'avance pour ces éclaircissements !
S'il y a d'autres points à éclaircir, ne pas hésiter à m'en faire part...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: Sécurité ?
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Développer une interface web avec le toolkit Atlas (1/2). Évalué à 7.
Merci de prendre le temps de s'y intéresser :-) !
C'est précisément pour cela que ce toolkit a été conçu.
À l'image de la philosophie derrière UNIX, le toolkit Atlas ne fait qu'une seule chose, et tente de le faire le mieux possible, à savoir faciliter le développement d'une interface graphique. De ce fait, il n'offre aucune fonctionnalité en terme d'authentification, de gestion d'accès, voire relatifs aux bases de données, comme peuvent le proposer certains frameworks. D'où son appellation de toolkit, et non de framework.
Ce n'est probablement pas évident au premier abord, mais l'ambition du toolkit Atlas n'est absolument pas d'être une alternative aux traditionnels frameworks de développement d"applications web, mais d'offrir un moyen simple et rapide d'ajouter une interface graphique à n'importe quel programme Python (dans le cas de la version Python du toolkit). Par conséquent, l'utilisation du toolkit Atlas dans un programme Python n'a pas plus d'influence sur ce à quoi ce programme Python a accès que s'il utilisait un toolkit comme PyQT. Le fait que l'utilisation du toolkit Atlas transforme de facto le programme en application web n'est, en quelque sorte, qu'un effet secondaire...
Entre le programme et le serveur auquel il se connecte, la connexion n'est, à ce jour, pas chiffrée. Ce qui n'empêche pas le toolkit Atlas d'être utilisé en production, mais c'est clairement dans le cas où les données transitant entre l'application et le serveur ne sont pas sensibles, ou alors c'est avec mise en œuvre de la solution de contournement décrite plus bas.
Actuellement, le toolkit, quelque soit sa version, est très léger et autonome, sans dépendances. Toutes les version du toolkit, même les versions qui peuvent être installées avec un gestionnaire de paquets, peuvent être fournies sous forme d'archive auto-suffisante, ce qui facilite son utilisation notamment dans un cadre éducatif. Ajouter le chiffrement rendrait l'installation du toolkit beaucoup plus compliquée, sans compter le travail que cela représente en matière de développement, tant au niveau du toolkit proprement dit, vu sa disponibilité pour plusieurs langages, que du serveur auquel il se connecte.
Cela ne signifie pas que ce chiffrement ne sera jamais disponible, mais ce sera probablement sous forme d'extension, ou d'une version distincte, peut-être spécialement destinée à un usage professionnel, avec connexion à serveur dédié...
On peut actuellement contourner ce problème en installant le logiciel serveur (qui est diffusé sous licence libre) sur une machine sur laquelle on installerait également le programme Python. De ce fait, les échanges programme/serveur ne sortiraient pas de la machine et ne pourraient donc être que très difficilement interceptés.
S'il y a d'autres points à éclaircir, ne pas hésiter à m'en faire part...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...