Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
John Mackerel
Pierre Goiffon wrote:
Ca implique aussi, surtout, qu'en CGI on fait un traitement en un bloc, alors qu'avec un module/NSAPI/ISAPI on peut dialoguer tout du long avec le client.
J'avoue ne pas trop comprendre, là. Pourriez-vous développer un peu, avec un exemple ?...
Je pensais aux Response.Buffer de ASP ou output_buffering de PHP. En CGI, on effectue tout son traitement et après on rend la main au serveur.
Je ne vois pas où est le _dialogue_ avec le client.
Pierre Goiffon wrote:
Ca implique aussi, surtout, qu'en CGI on fait un traitement en un
bloc, alors qu'avec un module/NSAPI/ISAPI on peut dialoguer tout du
long avec le client.
J'avoue ne pas trop comprendre, là. Pourriez-vous
développer un peu, avec un exemple ?...
Je pensais aux Response.Buffer de ASP ou output_buffering de PHP.
En CGI, on effectue tout son traitement et après on rend la main au
serveur.
Je ne vois pas où est le _dialogue_ avec le client.
Ca implique aussi, surtout, qu'en CGI on fait un traitement en un bloc, alors qu'avec un module/NSAPI/ISAPI on peut dialoguer tout du long avec le client.
J'avoue ne pas trop comprendre, là. Pourriez-vous développer un peu, avec un exemple ?...
Je pensais aux Response.Buffer de ASP ou output_buffering de PHP. En CGI, on effectue tout son traitement et après on rend la main au serveur.
Je ne vois pas où est le _dialogue_ avec le client.
loufoque
Pierre Goiffon a dit le 15/02/2005 à 09:56:
- dans les esprits de nombre d'admins CGI <=> prb de sécurité
CGI c'est la seule chose qui soit vraiment sécurisée. En recréant un processus à chaque fois, on peut spécifier l'uid de ce processus. Généralement, si on travaille dans un sous-repertoire de /home/users/unUtilisateur (où devrait se trouver l'espace personnel sur un serveur pour du mutualisé) on met l'uid d'unUtilisateur. Par contre, c'est sûr, si les admins sont mauvais et ne sont pas capables de gérer les droits des utilisateurs du système d'exploitation, ça peut poser des problèmes.
PHP ou autre en module ça tourne avec l'uid du serveur http. C'est à dire que tous les scripts PHP ont les mêmes droits d'accès. Pour limiter ça, on a créé le safe_mode, système interne à php censer sécuriser le truc. Enfin, ce n'est qu'une béquille...
Le fait d'être en CGI ou en module ne change principalement que deux choses : l'uid et donc les droits (enfin ça dépend de la configuration, sur de nombreux serveurs on a du cgi qui tourne avec un uid unique, c'est sans intérêt) et la performance. Après bon il y a des détails, les "Status" en entêtes, pas d'accès à des fonctions spécifiques au serveur, pathinfo légèrement différent... Rien d'extraordinaire.
Et c'est toujours plus sécurisant d'utiliser un langage de scripting où chaque méthodes pourra être bloquée au besoin, que de laisser un exécutable tout faire - même s'il tourne dans un environnement limité.
Donc en fait on résout un manque de compétences en gestion des droits du système d'exploitation par une limitation. C'est une idée.
- les CGI ne sont adaptés qu'à des traitements "simples", qui ne devraient pas connaitre des montées en charge énormes, mais qui ont quand même besoin de performance
Les CGI sont adaptés à des traitements complexes peu répétés et avec peu de concurrence, à cause des petits soucis de performance. Votre description c'est plutôt pour un module de scripting justement. S'il monte trop en charge, c'est là que c'est dangereux, car c'est tout le serveur qui plante.
- la différence principale entre CGI et module/NSAPI/ISAPI pour le développeur est que l'on est en dehors du serveur Web avec le 1er, et ça implique que l'on ne peut donc pas profiter de tout ce que le serveur peut offrir.
Mais qu'a-t-il donc à offrir de si extraordinaire ? La possibilité de faire des virtual ?
Ca implique aussi, surtout, qu'en CGI on fait un traitement en un bloc, alors qu'avec un module/NSAPI/ISAPI on peut dialoguer tout du long avec le client.
Dialoguer tout au long avec le client ? Un client demande une page, on lui donne, paf. Il en demande une autre, on la lui donne. C'est comme ça que fonctionne HTTP, désolé. Il n'y a pas de dialogue.
Après on a inventé le système des sessions, dans lesquelles on stocke des données spécifiques à un client identifié par chance par les paramètres qu'il transmet à son insu, session qui devient perimée après un certain temps d'inactivité.
Pierre Goiffon a dit le 15/02/2005 à 09:56:
- dans les esprits de nombre d'admins CGI <=> prb de sécurité
CGI c'est la seule chose qui soit vraiment sécurisée. En recréant un
processus à chaque fois, on peut spécifier l'uid de ce processus.
Généralement, si on travaille dans un sous-repertoire de
/home/users/unUtilisateur (où devrait se trouver l'espace personnel sur
un serveur pour du mutualisé) on met l'uid d'unUtilisateur.
Par contre, c'est sûr, si les admins sont mauvais et ne sont pas
capables de gérer les droits des utilisateurs du système d'exploitation,
ça peut poser des problèmes.
PHP ou autre en module ça tourne avec l'uid du serveur http.
C'est à dire que tous les scripts PHP ont les mêmes droits d'accès. Pour
limiter ça, on a créé le safe_mode, système interne à php censer
sécuriser le truc.
Enfin, ce n'est qu'une béquille...
Le fait d'être en CGI ou en module ne change principalement que deux
choses : l'uid et donc les droits (enfin ça dépend de la configuration,
sur de nombreux serveurs on a du cgi qui tourne avec un uid unique,
c'est sans intérêt) et la performance.
Après bon il y a des détails, les "Status" en entêtes, pas d'accès à des
fonctions spécifiques au serveur, pathinfo légèrement différent... Rien
d'extraordinaire.
Et c'est toujours plus sécurisant d'utiliser un langage de scripting où
chaque méthodes pourra être bloquée au besoin, que de laisser un
exécutable tout faire - même s'il tourne dans un environnement limité.
Donc en fait on résout un manque de compétences en gestion des droits du
système d'exploitation par une limitation.
C'est une idée.
- les CGI ne sont adaptés qu'à des traitements "simples", qui ne
devraient pas connaitre des montées en charge énormes, mais qui ont
quand même besoin de performance
Les CGI sont adaptés à des traitements complexes peu répétés et avec peu
de concurrence, à cause des petits soucis de performance.
Votre description c'est plutôt pour un module de scripting justement.
S'il monte trop en charge, c'est là que c'est dangereux, car c'est tout
le serveur qui plante.
- la différence principale entre CGI et module/NSAPI/ISAPI pour le
développeur est que l'on est en dehors du serveur Web avec le 1er, et ça
implique que l'on ne peut donc pas profiter de tout ce que le serveur
peut offrir.
Mais qu'a-t-il donc à offrir de si extraordinaire ? La possibilité de
faire des virtual ?
Ca implique aussi, surtout, qu'en CGI on fait un traitement
en un bloc, alors qu'avec un module/NSAPI/ISAPI on peut dialoguer tout
du long avec le client.
Dialoguer tout au long avec le client ?
Un client demande une page, on lui donne, paf. Il en demande une autre,
on la lui donne.
C'est comme ça que fonctionne HTTP, désolé. Il n'y a pas de dialogue.
Après on a inventé le système des sessions, dans lesquelles on stocke
des données spécifiques à un client identifié par chance par les
paramètres qu'il transmet à son insu, session qui devient perimée après
un certain temps d'inactivité.
- dans les esprits de nombre d'admins CGI <=> prb de sécurité
CGI c'est la seule chose qui soit vraiment sécurisée. En recréant un processus à chaque fois, on peut spécifier l'uid de ce processus. Généralement, si on travaille dans un sous-repertoire de /home/users/unUtilisateur (où devrait se trouver l'espace personnel sur un serveur pour du mutualisé) on met l'uid d'unUtilisateur. Par contre, c'est sûr, si les admins sont mauvais et ne sont pas capables de gérer les droits des utilisateurs du système d'exploitation, ça peut poser des problèmes.
PHP ou autre en module ça tourne avec l'uid du serveur http. C'est à dire que tous les scripts PHP ont les mêmes droits d'accès. Pour limiter ça, on a créé le safe_mode, système interne à php censer sécuriser le truc. Enfin, ce n'est qu'une béquille...
Le fait d'être en CGI ou en module ne change principalement que deux choses : l'uid et donc les droits (enfin ça dépend de la configuration, sur de nombreux serveurs on a du cgi qui tourne avec un uid unique, c'est sans intérêt) et la performance. Après bon il y a des détails, les "Status" en entêtes, pas d'accès à des fonctions spécifiques au serveur, pathinfo légèrement différent... Rien d'extraordinaire.
Et c'est toujours plus sécurisant d'utiliser un langage de scripting où chaque méthodes pourra être bloquée au besoin, que de laisser un exécutable tout faire - même s'il tourne dans un environnement limité.
Donc en fait on résout un manque de compétences en gestion des droits du système d'exploitation par une limitation. C'est une idée.
- les CGI ne sont adaptés qu'à des traitements "simples", qui ne devraient pas connaitre des montées en charge énormes, mais qui ont quand même besoin de performance
Les CGI sont adaptés à des traitements complexes peu répétés et avec peu de concurrence, à cause des petits soucis de performance. Votre description c'est plutôt pour un module de scripting justement. S'il monte trop en charge, c'est là que c'est dangereux, car c'est tout le serveur qui plante.
- la différence principale entre CGI et module/NSAPI/ISAPI pour le développeur est que l'on est en dehors du serveur Web avec le 1er, et ça implique que l'on ne peut donc pas profiter de tout ce que le serveur peut offrir.
Mais qu'a-t-il donc à offrir de si extraordinaire ? La possibilité de faire des virtual ?
Ca implique aussi, surtout, qu'en CGI on fait un traitement en un bloc, alors qu'avec un module/NSAPI/ISAPI on peut dialoguer tout du long avec le client.
Dialoguer tout au long avec le client ? Un client demande une page, on lui donne, paf. Il en demande une autre, on la lui donne. C'est comme ça que fonctionne HTTP, désolé. Il n'y a pas de dialogue.
Après on a inventé le système des sessions, dans lesquelles on stocke des données spécifiques à un client identifié par chance par les paramètres qu'il transmet à son insu, session qui devient perimée après un certain temps d'inactivité.
