Support de proxy inverse / équilibreur [Reverse-Proxy / Balancer support]

Fonctionnement derrière un équilibreur de charge de couche 7 (proxy inverse HTTP)

Dans un changement de cloud, il peut être judicieux de ne pas connecter le serveur directement à Internet, mais de le faire fonctionner derrière un loadbalancer ou un reverse proxy.

Ceux-ci peuvent également se charger de la terminaison SSL. On évite ainsi de conserver un certificat SSL public sur le serveur lui-même.

Mais pour que l' AppServer reçoive l'IP du client et le nom d'hôte utilisé, il doit faire confiance au reverse proxy. Pour ce faire, le reverse proxy envoie des en-têtes personnalisés à l' AppServer (X-Forwarded-For, X-Forwarded-Proto), dans lesquels il communique les données originales. Par défaut, l' AppServer n'évalue toutefois pas ces en-têtes. Cela constituerait une faille de sécurité, car sinon tout appelant externe pourrait se faire passer pour une autre machine.

Il est possible de modifier ce comportement via les paramètres de l'onglet Cloud Support de la Config du service AppServer. Il est recommandé de ne débloquer explicitement que les adresses IP du reverse proxy.

CORS-Origins supplémentaires [Additional CORS origins]

La Same-Origin-Policy (SOP) interdit le téléchargement à partir d'autres serveurs lors de la visite d'un site web. Toutes les données doivent provenir de la même source, c'est-à-dire du même serveur. Il s'agit d'une mesure de sécurité, car JavaScript et CSS peuvent charger des contenus d'autres serveurs à l'insu de l'utilisateur, y compris des contenus nuisibles. Une telle tentative d'accès est appelée Cross-Origin-Request. Mais si les deux exploitants de sites Web sont au courant de l'échange de données et qu'ils le souhaitent, il est possible d'autoriser le processus. Le serveur demandé - donc celui à partir duquel les contenus doivent être rechargés - autorise alors l'accès par Cross-Origin Resource Sharing.

Services de tunneling WebSocket [WebSocket tunneling services]

Tunneling WebSocket pour les protocoles personnalisés

PARTsolutions utilise, en plus de HTTPS, d'autres protocoles binaires (MZCOM ou le protocole de licence) qui sont des protocoles binaires propriétaires. MZCOM représente ici un protocole de messagerie orienté flux qui permet de mettre en œuvre une communication asynchrone entre le client et l'AppServer.

Le protocole de licence est quant à lui utilisé pour attribuer/libérer des licences. L'occupation est liée à une connexion permanente avec le serveur de licences.

Ces deux protocoles ne peuvent pas être mis en œuvre via HTTPS. Ils peuvent toutefois être mis en tunnel via WebSocket (un sous-protocole HTTPS).

Cela présente des avantages, mais aussi des inconvénients :

L'activation du WebSocket Tunneling se fait dans la catégorie PARTsolutions > Application Server > AppServer Service, sur la page d'onglet Cloud-Support. Cette fonctionnalité est activée par défaut. Si elle ne doit pas être utilisée, il faut décocher la case correspondante.

Onglet "Assistance cloud [Cloud-Support]"

Options de configuration côté client

Sur les clients, elle doit être activée explicitement via la variable d'environnement CADENAS_APPSERVER :

CADENAS_APPSERVER=https://<servername>?ws=1&flm=1

L'avantage de la mise en marche via la variable d'environnement est que l'on peut aussi conduire des configurations mixtes :

À propos de l' start.env pouvez le faire via des conditions Les blocages varient également en fonction de l’ordinateur/de l’environnement peut être configuré.

Accès à l'Api [Api access]

Forcer l'accès authentifié [Enforce authenticated access]:

Préfixes libres: aucune clé API n'est nécessaire pour les services inscrits. Les intégrations PDM utilisent uniquement le service 3df-config.

Pour forcer l'accès authentifié, procédez comme suit :

Lors de la mise en place d'une installation de PARTsolutions Enterprise, tenez compte des points suivants :

Spécification explicite du nom d'hôte pour le serveur de licence

Le système de licence dispose normalement de la possibilité d'auto-découverte. Cela signifie que le serveur de licences envoie ses données (y compris la configuration de sauvegarde) au client sur demande, afin que celui-ci puisse s'adresser automatiquement et correctement aux serveurs de licences.

Cette fonctionnalité ne peut pas fonctionner dans un environnement cloud où le nom d'hôte public ne correspond pas au nom interne du serveur de licence. Pour que cela soit tout de même possible, le nom d'hôte (normalement déterminé automatiquement) peut être remplacé par config.

Pour cela, dans la catégorie Serveurs de licences [License server], sous l'onglet Sécurité [Security], il est possible d'indiquer explicitement sous Écraser le nom du serveur (pour les serveurs cloud et firewalled) [Override server names (for cloud and firewalled servers)] un nom DNS que le serveur doit communiquer aux clients pendant la phase d'auto-découverte.