Discussion :

[WDKyle]

Bonsoir à tous !

J'ai besoin pour une application de recevoir/envoyer des données depuis/vers des applications extérieur (appli Windows, Appli mobile, site web, etc...).

Je peux évidement déployer un web service mais cela implique de mettre en place un serveur web (Apache/IIS) voir même un serveur d'application Webdev.

Mais cela deviens bien lourd à mettre en place et je me demandais s'il ne serais pas possible d'un point de vue sécurité de créer un petit serveur web en Windev (j'ai des projets sources qui le permette) et donc d'envoyer directement des requêtes POST/GET à une page web hébergée par ce petit serveur web ?

Il y aurait dans ce cas pour mes clients, juste un port à débloquer sur leur pc et routeur.

Cordialement,

[tatayo]

Bonjour,
Que le service soit exposé via un site Web IIS, Apache ou WinDev, ou via un Webservice (webdev ou autre), le niveau de sécurité sera à mon avis peu ou prou le même.
Ca revient dans tous les cas à exposer le port 80 sur Internet...
Reste à connaitre le "niveau de risque acceptable" pour les clients.

Tatayo.

[WDKyle]

Oui, effectivement... Mais donc quels risques peuvent survenir ?

Merci

[DelphiManiac]

Des risques de sécurité liés au développement du serveur Web, principalement.

Par exemple, faire un get sur n'importe quel fichier du disque si lors du get tu ne contrôle pas précisément à quoi à accès le client.

Des risques liés au fait que n'importe qui pourra se connecter au port de la machine.

Attaque par déni de service = blocage de la connexion internet du client.

Ce ne sont que 2 exemples parmi tant d'autres possible.


Le protocole HTTP devra être respecté à la lettre, le site étant accessible de tout le monde.

Personnellement, j'aurais plutôt tendance à développer un petit protocole propriétaire. Tu as toujours des risques de sécurité mais pas d'obligation de respecter HTTP.

[WDKyle]

Des risques de sécurité liés au développement du serveur Web, principalement.

Par exemple, faire un get sur n'importe quel fichier du disque si lors du get tu ne contrôle pas précisément à quoi à accès le client.

Des risques liés au fait que n'importe qui pourra se connecter au port de la machine.

Attaque par déni de service = blocage de la connexion internet du client.

Ce ne sont que 2 exemples parmi tant d'autres possible.


Le protocole HTTP devra être respecté à la lettre, le site étant accessible de tout le monde.

Personnellement, j'aurais plutôt tendance à développer un petit protocole propriétaire. Tu as toujours des risques de sécurité mais pas d'obligation de respecter HTTP.

D'accord :s

Mais je suis obliger de passer soit par un web service ou du moins requete HTTP pour être standard à un maximum d'applications...

Tu pensais à quoi comme protocole propriétaire ?

[DelphiManiac]

Si tu as besoin que n'importe quelle application puisse se connecter à ton serveur, il faut bien sûr que tu restes dans un standard.

Si tu n'a pas cette contrainte, tu peux imaginer tout protocole propriétaire qui satisferait à tes besoins. Jette un œil sur le protocle SMTP par exemple, c'est un protocole texte simple qui peut te donner des idées.

Il te faut donc déjà répondre à cette question, dois je être standard ou pas !

[WDKyle]

Je dois être standard oui, je n'ai pas le choix...Mon application dois recevoir de données provenant de services SMS par requête HTTP (POST/GET)

[DelphiManiac]

Alors autant faire un déploiement d'un serveur web, Apache ou nginx plus "léger " qu'Apache.

[WDKyle]

Merci pour ton aide DelphiManiac

J'ai réfléchi et le mieux est de rester sur un web service, c'est plus sûr... (n'est-ce pas ?)

Après, j'hésite entre :

- Héberger moi-même ce web service sur un serveur
(Dans ce cas, pas d'installation/configuration complexe pour le client et il n'as pas de serveur à gérer)

- Laisser le client installer le web service sur son serveur
(Le client gère l'installation/configuration du web service et la gestion de son serveur)

Votre avis svp ?

[DelphiManiac]

Si la solution d'hébergement sur un serveur externe est envisageable, je vote pour cette solution sans hésitation.

- Pas de pare feu à configurer, en sachant que beaucoup de pare feu différent existent, tout ceux qui sont dans les logiciels antivirus.
- Pas de box à configurer pour le routage.
- Pas de problème de laisser la machine du client allumer
- Moins de risque de sécurité sur un serveur linux dédié à l'hébergement
- etc....

[WDKyle]

D'accord

Par contre, connaissez-vous de bons hébergeur de web service Windev ?

Je connais de nom Kalanda, est-ce bien ?

J'ai peur de ne pas pouvoir maîtriser la gestion complète d'un serveur dédié Windows...

[OnePoint]

Bonjour à tous,

WDKyle, pour enrichir le panorama des possibilités qui s'offrent à toi, connais-tu WDScript ?

C'est un système basé sur des pages de scripts (similaire à PHP) mais en WLangage.

Un atout important de WDScript est qu'il fonctionne dans une architecture serveur web standard, sous Windows ou sous Linux (!)... avec tous les avantages que cela peut procurer, notamment pour gérer la montée en charge.

Pour ta problématique de sécurité, on peut clairement distinguer: le "côté serveur web" et le "côté application" (c'est à dire les pages de scripts).

Avec WDScript tu te concentres sur le côté application et tu ne t'occupes pas du protocole HTTP, les problèmes de performance, etc..

Si tu te demandes quelle est la relation avec Windev...
Eh bien, dans une page de script, il est possible de faire appel à des bibliothèques WDL et aussi directement à des fenêtres Windev (qui ne servent pas à l'affichage, mais plutôt comme un container pour une "logique" d'exécution: FichierVersEcran et/ou EcranVersFichier, exécuter du code, etc.)

Des liens en vrac:
http://sourceforge.net/projects/wdscript/
http://wdscript.sourceforge.net/
http://sourceforge.net/apps/trac/wdscript/wiki

et sur le site de Tanguy Pruvot.
http://tanguy.ath.cx/index.php?q=wdscript261

[WDKyle]

Merci pour ton soutien OnePoint mais pour moi le mieux serais que je trouve une solution "plug & play"...

Car même avec WDScript il faut un dédié/virtuel sous Windows ou Linux et le gérer...

[OnePoint]

Merci pour ton soutien OnePoint mais pour moi le mieux serais que je trouve une solution "plug & play"...

Car même avec WDScript il faut un dédié/virtuel sous Windows ou Linux et le gérer...

Sans malice de ma part, je me demande ce que tu mets dans la catégorie "Plug & Play" ...
un webservice développé avec Windev ou Webdev (Wx) ?

C'est vrai que je n'ai pas une grande expérience des webservices Wx, mais il me semble que, en plus du développement pur, il y aura quand même pas mal de travail sur l'architecture matérielle et sa configuration.

A la problématique initiale de Sécurité, tu rajoutes maintenant la facilité de déploiement (Plug & Play)... trouveras-tu le bonheur ?

[WDKyle]

Si je choisi d'héberger le web service chez Kalanda par exemple, je ne vais pratiquement rien à voir à gérer logiquement ? Du moins pas le coté matériel ni config du serveur.

[OnePoint]

Si je choisi d'héberger le web service chez Kalanda par exemple, je ne vais pratiquement rien à voir à gérer logiquement ? Du moins pas le coté matériel ni config du serveur.

Ce que je comprends c'est que tu vas devoir investir dans Webdev aussi, non ?


Et autre piste... Pour la simplicité, il y a le service PCSCloud qui, en théorie, doit être plus ou moins intégré avec l'EDI.

http://www.pcsoft.fr/webdev/cloud.htm

Mais faut-il faire preuve de prudence avec les promesses de PC Soft ?

Qui utilise PCSCloud ?

[WDKyle]

Il y à des frais de mise en service important avec Pscloud...

Je ne vois pas oû il faut une licence Webdev pour utiliser un hébergement Webdev chez Kalanda ?

Je crée mes web services directement depuis Windev.