Forum Ametys
You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 Re: Administration » Migration 3.5.3 à 3.5.4 » 24/04/2014 14:43:58
Merci, pour cette réponse.
J'ai fait le passage temporaire en mode debug puis un nettoyage total des caches de chrome (qui sont un peu trop tenaces à mon goût 
) et ça marche beaucoup mieux.
#2 Administration » Migration 3.5.3 à 3.5.4 » 24/04/2014 11:59:29
- gafou
- Replies: 2
Bonjour,
Suite à la sortie de la version 3.5.4 (et surtout pour la correction du bug sous chrome), j'ai voulu mettre à jour mon serveur pour le passer de la 3.5.3 à la 3.5.4.
Pour ce faire, n'ayant pas vu de note particulière au sujet de la mise à jour, j'ai juste changées les librairies du front-office et du back-office.
Hors, j'ai toujours les bug sous chrome.
Par exemple si j'essaie de créer un nouveau site, j'ai toujours des erreurs js qui semble liée au problème original :
"return conn.responseXML.selectSingleNode("/responses/response[@id='0']");"
La nouvelle version du fichier mozxpath.js n'est pas chargée alors que la librairie ametys-runtime-resources-2.5.4.jar contenant le bon fichier est bien déployée dans le dossier cms/WEB-INF/lib.
J'ai bien vidé les dossiers temp et work du tomcat.
Y a-t-il une étape supplémentaire nécessaire pour mener à bien la migration de la version 3.5.3 à 3.5.4 ?
Un cache particulier sur le back-office qu'il faudrai purger ?
Cordialement,
#3 Paramétrage et intégration » Héritage de zone skin et cache » 15/04/2014 15:16:10
- gafou
- Replies: 1
Bonjour,
La question est doublement intégration / administration.
Dans une zone de ma skin, j'ai un service non cachable qui est définit. Ce service corresponds à des données utilisateur quand celui-ci est connecté en front.
Bien que le service ne soit pas cacheable, dans les pages qui en héritent de la skin, mon service semble être en cache.
Ce qui m'amène a deux question :
- la gestion du cache ne prend-elle pas en compte dans son calcul de 'cachabilité' de la page les élèments hérités de la skin ?
- comment désactivé de manière général le cache des pages ?
Merci d'avance,
#4 Re: Paramétrage et intégration » Page de login : afficher du contenu contribué » 26/03/2014 12:09:03
Bonjour,
Il me semblait aussi que contourner toute la machinerie de gestion du login était plutôt risqué.
Du coup, je l'ai gardé mais de manière caché à l'utilisateur avec un appel Ajax sur la page tagguée pour le login.
Celà me permets d'avoir mon propre formulaire de login, sur une page normale tout en continuant d'utiliser le login ametys de base.
Ce n'est pas très éléguant, mais ça marche.
#5 Re: Paramétrage et intégration » Affichage conditionnel selon le mode » 12/03/2014 13:00:05
Bonjour,
J'ai cru observer qu'il est possible d'utiliser l'attribut "$rendering-context" avec les valeurs suivantes :
- 'back'
- 'front'
- 'preview'
Donc en ajoutant la balise suivante autour du logo ça devrait marcher :
<xsl:if test="$rendering-context != 'back'"></xsl:if>#6 Paramétrage et intégration » Page de login : afficher du contenu contribué » 12/03/2014 12:55:31
- gafou
- Replies: 2
Bonjour,
Aucun contenu ne semble accéssible lors de l'accès à la page de login (http://localhost:8080/_authenticate?requestedURL=/fr/index.html)
Hors j'ai du contenu contribué dans le header de ma skin, hors celui-ci n'est pas accessible sur le login (une remontée de contenu en carousel).
Comment faire pour afficher ce contenu contribué sur le login ?
#7 Re: Paramétrage et intégration » Authentification front globale » 07/03/2014 16:22:47
Pour une raison que je ne m'explique pas, ma redirection vers la page courante repasse quand même par _authenticate, et ce même après changement de mon url getLoginFailedURL ("_generate/" + getSite() + ContextHelper.getRequest(_context).getParameter("requestedURL")+"?loginfailed=true").
Url login failed :
_generate/monsite/fr/index.html?loginfailed=true
Logs :
2014-03-07 15:05:22,369 INFO [sitemap] Redirecting to 'cocoon://_generate/monsite/fr/index.html?loginfailed=true&login=456456'
2014-03-07 15:05:22,482 INFO [access] '_authenticate' Processed by Apache Cocoon 2.1.11 in 116 milliseconds.URL de la page affichée en retour erreur :
http://localhost:8080/_authenticate?requestedURL=/fr/index.html
J'ai l'impression que c'est l'ajout du paramètre "login=456456" qui déclenche la redirection sur _authenticate.
De quoi celà peut-il venir ? Y aurait-il un autre élément à surcharger ?
#8 Re: Paramétrage et intégration » Authentification front globale » 06/03/2014 15:05:33
Bonjour,
Merci pour cette réponse.
Il me reste le problème du retrour en erreur du formulaire. En effet, en cas d'erreur sur la connexion, le retour va obligatoirement sur le xsl de login (skin/maskin/services/web/pages/frontoffice-login/login.xsl) qui remplace le contenu de la page par le login.
Y a-t-il un moyen de le faire renvoyer sur le xsl de la page courante, avec la gestion des erreurs au niveau du formulaire custom ?
#9 Paramétrage et intégration » Authentification front globale » 06/03/2014 11:43:38
- gafou
- Replies: 6
Bonjour,
J'ai besoin pour mon site de permettre à l'utilisateur de s'authentifier sur le front.
J'ai donc fait des premier tests avec le système de gestion des utilisateurs front existant : login/inscription/gestion des données utilisateur ()
Hors, je n'ai pas vu de possibilité d'afficher le login - mode "Vous avez déjà un compte"- hors des pages a accés limité.
J'ai mis mon service sign-up dans l'en-tête de mes pages mais il n'apparait qu'on mode "Inscription".
Y a-t-il un moyen simple de mettre en place une authentification utilisateur front globale et non pas aux pages d'accès restreint ?
Pages: 1