J’ai eu quelques difficultés à me connecter à un dépôt SCENARIchain-server 5.0 d’une part et SCENARIsuite-starter 5.0 d’autre part, sur le même serveur, à partir de SCENARIchain-client 5.0.
Pour accéder à SCENARIchain-server 5.0, l’URL de type https://mon.domaine.tld/scenarichain-server5.0 fonctionne (code 200 à la requête "GET /scenarichain-server5.0/public/u/authInfos HTTP/1.1" 200), tandis que pour accéder à SCENARIsuite-starter 5.0, l’URL de type https://mon.domaine.tld/scenarisuite-starter5.0/~~chain doit être utilisée (sous peine d’erreur 404 : "GET /scenarisuite-starter5.0/public/u/authInfos HTTP/1.1" 404, au lieu du code 200 à la requête "GET /scenarisuite-starter5.0/~~chain/public/u/authInfos HTTP/1.1" 200)
J’ai seulement repéré la différence suivante dans les fichiers /~~static/chain/fr-FR/confAuth.js et /~~static/chain/fr-FR/conf.js, respectivement (avec diff) qui me semble peut-être reliée au comportement observé :
Enfin, un comportement légèrement différent est observé en utilisant SCENARIclientNG 5.0, qui impose d’utiliser l’adresse du type https://mon.domaine.tld/scenarisuite-starter5.0/ (avec le slash final) contre https://mon.domaine.tld/scenarichain-server5.0 (sans slash). Les redirections adéquates ont alors lieu.
En effet SCENARIsuite-starter contient deux portlets (sous-webapps) : un dépôt qui est accessible depuis la racine de la web app et un chain pour l’écriture qui du coup ne peut pas être accessible depuis la racine, elle est donc une URL technique « /~~chain » faute de mieux, ceci est paramétrabe dans SCENARbuilder quen on veux concevoir sa propre webapp.
A l’inverse SCENARIchain-server ne contient qu’un seul portlet (le chain) du coup il est câblépour répondre depuis la racine de la webapp.
Normalement on ne doit pas avoir à installer SCENARIchain-server ET SCENARIsuite-starter, c’est innutile vu que SCENARIsuite-starter contient déjà un SCENARIchain-server.
Décidément je ferai bien d’apprendre à lire avant toute chose !
Petite note en coin : le dépôt n’est accessible depuis la racine (/) qu’après avoir ouvert une session de connexion (identifiant/mot de passe) depuis le formulaire de connexion (auquel on peut accéder par exemple depuis /& et la redirection qui en découle) ; sans connexion préalable, on n’a de fait pas accès au dépôt (code 403, accès non autorisé). On pourrait s’attendre à être redirigé vers le formulaire de connexion à ce moment-là.
J’ai installé les deux pour voir en pratique les différences (ce que permet le dépôt de suite-starter) que je n’avais pas perçues à la lecture de la documentation, afin de cerner lequel des deux serait le plus pertinent pour mon usage.
Le dépôt associé au serveur de production de contenu est un vrai PLUSSS.
Il simplifie +++ la mise en ligne (et donc l’accès) de toutes les publications.
Autre +++, il transforme « automatiquement » toute vidéo déposée dedans en différents formats et adapte en conséquence la source envoyée vers le terminal de consultation : exemple : basse def. si connexion lente sur smartphone, HD si connexion par câble.
Un point à souligner « en revanche » : le dépôt est public => tout publication mise en ligne sur le dépôt est accessibles à toute personne disposant de l’URL. Il existe un mode de « contournement », par exemple en créant des URL complexes ET en « cachant » le dossier ou la publication déposée, mais ce n’est pas un vrai mode privé à accès contrôlé par LOGIN / MdP.(FAUX cf. ci dessous)
Hello @sam,
Donc ma remarque : Un point à souligner « en revanche » : le dépôt est public => tout publication mise en ligne sur le dépôt est accessibles à toute personne disposant de l’URL. Il existe un mode de « contournement », par exemple en créant des URL complexes ET en « cachant » le dossier ou la publication déposée, mais ce n’est pas un vrai mode privé à accès contrôlé par LOGIN / MdP. n’a plus lieu d’être, Tu confirmes ?