Valoriser le patrimoine numérique scientifique, pédagogique et documentaire des universités et le partager par un réseau de portails communicants en OAI

> Bonjour Yannis,
>
> Je réponds dans le message
>
> Yannis Roualdes wrote:

>> Bonjour à tous,
>>
>> Cette question vous paraîtra peut être stupide mais je découvre
>> LDAP (et ses filtres).
>> Premièrement il me semble, mais détrompez moi s'il le faut, qu'il
>> n'est pas nécessaire d'avoir des groupes LDAP scpécifiques pour
>> utiliser le workflow, si j'ai bien compris on peut tout à fait gérer
>> ces groupes avec les paramètres LDAP du workflow.

> Dans le workflow, le terme acegi "recipient" représente soit un
> utilisateur, soit un groupe d'utilisateurs , soit un role. On peut
> donc en effet se passer de la notion de groupe d'utilisateurs. On peut
> par exemple attribuer le role "MODERATOR" directement à plusieurs
> utilisateurs.
>
> Les "recipient" groupes ne sont qu'une facilité de définition et
> d'administration des utilisateurs et de leurs roles .
>

>> C'est là mon problème : je suis bien reconnu lors de
>> l'authentification CAS, mais lorsque j'affiche le profil dans
>> l'interface si l'uid est correct je n'ai aucune autre information, je
>> n'appartiens à aucun groupe et je n'ai donc aucune autorisation. Le
>> filtre que j'utilise dans commons-parameters.properties pour
>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid). Pour les
>> autres paramètres c'est similaire.

> Le seul groupe par défaut est "all" . L'utilisateur doit en faire
> partie , sinon il ne pourra rien faire .
> Par défaut, toutes les entrées ldap de classes Person (ie tous les
> utilisateurs) en font partie :
> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>

>> J'ignore totalement pourquoi ça ne fonctionnement pas, me faut il
>> modifier des fichies ACEGI ?

> En général, dès que l'on modifie les droits: persmissions ou roles (en
> gros, dès que l'on touche à acegi-acls-root.xml, il faut faire :
> ant update-acls

>> J'ai fait une recherche mais je n'ai pas trouvé de réponse, ou alors
>> j'ai du passer à côté, si c'est le cas veuillez m'excuser.
>> Merci pour votre aide.
>>

>
> Je ne suis pas sûr de répondre complètement à la question, car je ne
> connais pas ta configuration.
>
> Henri

> Bonjour,
>
> est-il possible de voir la config locale, au moins les fichiers :
> commons-parameters.properties
> conf/properties/spring/spring-categories.xml
> conf/properties/spring/spring-metadata-types.xml
> conf/propertiesspring/acegi/acegi-*.xml
>
> Henri
>
> Yannis Roualdes a écrit :

>> Bonjour,
>>
>> Merci pour cette réponse, elle confirme qu'il n'est pas nécessaire
>> de créer des groupes LDAP spécifiques à ORI-OAI, cela m'arrange.
>> Pour ce qui est du groupe "all" j'ai fait plusieurs tests et
>> quelque soit le filtre WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand je
>> me connecte je ne fais partie d'aucun groupe. J'ai bien spécifié
>> l'intitulé exact de l'objectClass pour le personnel de notre
>> établissement. En fait je ne vois pas où j'ai pu me tromper c'est
>> pourquoi je bloque.
>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL soit égal à
>> (objectClass=Person) ou à (uid=moniud) ça ne marche pas.
>> Bonne journée.
>>
>> Henri Jacob a écrit :

>>> Bonjour Yannis,
>>>
>>> Je réponds dans le message
>>>
>>> Yannis Roualdes wrote:

>>>> Bonjour à tous,
>>>>
>>>> Cette question vous paraîtra peut être stupide mais je découvre
>>>> LDAP (et ses filtres).
>>>> Premièrement il me semble, mais détrompez moi s'il le faut, qu'il
>>>> n'est pas nécessaire d'avoir des groupes LDAP scpécifiques pour
>>>> utiliser le workflow, si j'ai bien compris on peut tout à fait
>>>> gérer ces groupes avec les paramètres LDAP du workflow.

>>> Dans le workflow, le terme acegi "recipient" représente soit un
>>> utilisateur, soit un groupe d'utilisateurs , soit un role. On peut
>>> donc en effet se passer de la notion de groupe d'utilisateurs. On
>>> peut par exemple attribuer le role "MODERATOR" directement à
>>> plusieurs utilisateurs.
>>>
>>> Les "recipient" groupes ne sont qu'une facilité de définition et
>>> d'administration des utilisateurs et de leurs roles .
>>>

>>>> C'est là mon problème : je suis bien reconnu lors de
>>>> l'authentification CAS, mais lorsque j'affiche le profil dans
>>>> l'interface si l'uid est correct je n'ai aucune autre information,
>>>> je n'appartiens à aucun groupe et je n'ai donc aucune autorisation.
>>>> Le filtre que j'utilise dans commons-parameters.properties pour
>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid). Pour les
>>>> autres paramètres c'est similaire.

>>> Le seul groupe par défaut est "all" . L'utilisateur doit en faire
>>> partie , sinon il ne pourra rien faire .
>>> Par défaut, toutes les entrées ldap de classes Person (ie tous les
>>> utilisateurs) en font partie :
>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>

>>>> J'ignore totalement pourquoi ça ne fonctionnement pas, me faut il
>>>> modifier des fichies ACEGI ?

>>> En général, dès que l'on modifie les droits: persmissions ou roles
>>> (en gros, dès que l'on touche à acegi-acls-root.xml, il faut faire :
>>> ant update-acls

>>>> J'ai fait une recherche mais je n'ai pas trouvé de réponse, ou
>>>> alors j'ai du passer à côté, si c'est le cas veuillez m'excuser.
>>>> Merci pour votre aide.
>>>>

>>>
>>> Je ne suis pas sûr de répondre complètement à la question, car je ne
>>> connais pas ta configuration.
>>>
>>> Henri

>>
>>

>

> Je ne vois rien d'incorrect.
> Le problème vient surement d'une mauvaise définition des groupes
> additionnels .
> Il faut vérifier la valeur des paramètres :
> ldap.virtualgroup.filter.all, ldap.virtualgroup.filter.moderators,
> ldap.virtualgroup.filter.admins
> Le mapping ldap est sans doute erroné.
>
> Désolé de ne pas pouvoir faire plus.
> Henri
>
> Yannis Roualdes a écrit :

>> Bonjour,
>>
>> Excusez moi pour cette réponse tardive, en pièce jointe vous
>> trouverez l'archive de ces fichiers. Il est possible que le problème
>> vienne des intitulés des propriétés utilisé dans notre annuaire, je
>> teste en ce moment même.
>> Cordialement.
>>
>> Henri Jacob a écrit :

>>> Bonjour,
>>>
>>> est-il possible de voir la config locale, au moins les fichiers :
>>> commons-parameters.properties
>>> conf/properties/spring/spring-categories.xml
>>> conf/properties/spring/spring-metadata-types.xml
>>> conf/propertiesspring/acegi/acegi-*.xml
>>>
>>> Henri
>>>
>>> Yannis Roualdes a écrit :

>>>> Bonjour,
>>>>
>>>> Merci pour cette réponse, elle confirme qu'il n'est pas
>>>> nécessaire de créer des groupes LDAP spécifiques à ORI-OAI, cela
>>>> m'arrange.
>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs tests et
>>>> quelque soit le filtre WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand
>>>> je me connecte je ne fais partie d'aucun groupe. J'ai bien spécifié
>>>> l'intitulé exact de l'objectClass pour le personnel de notre
>>>> établissement. En fait je ne vois pas où j'ai pu me tromper c'est
>>>> pourquoi je bloque.
>>>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL soit égal à
>>>> (objectClass=Person) ou à (uid=moniud) ça ne marche pas.
>>>> Bonne journée.
>>>>
>>>> Henri Jacob a écrit :

>>>>> Bonjour Yannis,
>>>>>
>>>>> Je réponds dans le message
>>>>>
>>>>> Yannis Roualdes wrote:

>>>>>> Bonjour à tous,
>>>>>>
>>>>>> Cette question vous paraîtra peut être stupide mais je
>>>>>> découvre LDAP (et ses filtres).
>>>>>> Premièrement il me semble, mais détrompez moi s'il le faut, qu'il
>>>>>> n'est pas nécessaire d'avoir des groupes LDAP scpécifiques pour
>>>>>> utiliser le workflow, si j'ai bien compris on peut tout à fait
>>>>>> gérer ces groupes avec les paramètres LDAP du workflow.

>>>>> Dans le workflow, le terme acegi "recipient" représente soit un
>>>>> utilisateur, soit un groupe d'utilisateurs , soit un role. On peut
>>>>> donc en effet se passer de la notion de groupe d'utilisateurs. On
>>>>> peut par exemple attribuer le role "MODERATOR" directement à
>>>>> plusieurs utilisateurs.
>>>>>
>>>>> Les "recipient" groupes ne sont qu'une facilité de définition et
>>>>> d'administration des utilisateurs et de leurs roles .
>>>>>

>>>>>> C'est là mon problème : je suis bien reconnu lors de
>>>>>> l'authentification CAS, mais lorsque j'affiche le profil dans
>>>>>> l'interface si l'uid est correct je n'ai aucune autre
>>>>>> information, je n'appartiens à aucun groupe et je n'ai donc
>>>>>> aucune autorisation. Le filtre que j'utilise dans
>>>>>> commons-parameters.properties pour
>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid). Pour les
>>>>>> autres paramètres c'est similaire.

>>>>> Le seul groupe par défaut est "all" . L'utilisateur doit en
>>>>> faire partie , sinon il ne pourra rien faire .
>>>>> Par défaut, toutes les entrées ldap de classes Person (ie tous les
>>>>> utilisateurs) en font partie :
>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>

>>>>>> J'ignore totalement pourquoi ça ne fonctionnement pas, me faut il
>>>>>> modifier des fichies ACEGI ?

>>>>> En général, dès que l'on modifie les droits: persmissions ou roles
>>>>> (en gros, dès que l'on touche à acegi-acls-root.xml, il faut faire :
>>>>> ant update-acls

>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de réponse, ou
>>>>>> alors j'ai du passer à côté, si c'est le cas veuillez m'excuser.
>>>>>> Merci pour votre aide.
>>>>>>

>>>>>
>>>>> Je ne suis pas sûr de répondre complètement à la question, car je
>>>>> ne connais pas ta configuration.
>>>>>
>>>>> Henri

>>>>
>>>>

>>>

>>
>>

>

> Je ne vois rien d'incorrect.
> Le problème vient surement d'une mauvaise définition des groupes
> additionnels .
> Il faut vérifier la valeur des paramètres :
> ldap.virtualgroup.filter.all, ldap.virtualgroup.filter.moderators,
> ldap.virtualgroup.filter.admins
> Le mapping ldap est sans doute erroné.
>
> Désolé de ne pas pouvoir faire plus.
> Henri
>
> Yannis Roualdes a écrit :

>> Bonjour,
>>
>> Excusez moi pour cette réponse tardive, en pièce jointe vous
>> trouverez l'archive de ces fichiers. Il est possible que le problème
>> vienne des intitulés des propriétés utilisé dans notre annuaire, je
>> teste en ce moment même.
>> Cordialement.
>>
>> Henri Jacob a écrit :

>>> Bonjour,
>>>
>>> est-il possible de voir la config locale, au moins les fichiers :
>>> commons-parameters.properties
>>> conf/properties/spring/spring-categories.xml
>>> conf/properties/spring/spring-metadata-types.xml
>>> conf/propertiesspring/acegi/acegi-*.xml
>>>
>>> Henri
>>>
>>> Yannis Roualdes a écrit :

>>>> Bonjour,
>>>>
>>>> Merci pour cette réponse, elle confirme qu'il n'est pas
>>>> nécessaire de créer des groupes LDAP spécifiques à ORI-OAI, cela
>>>> m'arrange.
>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs tests et
>>>> quelque soit le filtre WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand
>>>> je me connecte je ne fais partie d'aucun groupe. J'ai bien spécifié
>>>> l'intitulé exact de l'objectClass pour le personnel de notre
>>>> établissement. En fait je ne vois pas où j'ai pu me tromper c'est
>>>> pourquoi je bloque.
>>>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL soit égal à
>>>> (objectClass=Person) ou à (uid=moniud) ça ne marche pas.
>>>> Bonne journée.
>>>>
>>>> Henri Jacob a écrit :

>>>>> Bonjour Yannis,
>>>>>
>>>>> Je réponds dans le message
>>>>>
>>>>> Yannis Roualdes wrote:

>>>>>> Bonjour à tous,
>>>>>>
>>>>>> Cette question vous paraîtra peut être stupide mais je
>>>>>> découvre LDAP (et ses filtres).
>>>>>> Premièrement il me semble, mais détrompez moi s'il le faut, qu'il
>>>>>> n'est pas nécessaire d'avoir des groupes LDAP scpécifiques pour
>>>>>> utiliser le workflow, si j'ai bien compris on peut tout à fait
>>>>>> gérer ces groupes avec les paramètres LDAP du workflow.

>>>>> Dans le workflow, le terme acegi "recipient" représente soit un
>>>>> utilisateur, soit un groupe d'utilisateurs , soit un role. On peut
>>>>> donc en effet se passer de la notion de groupe d'utilisateurs. On
>>>>> peut par exemple attribuer le role "MODERATOR" directement à
>>>>> plusieurs utilisateurs.
>>>>>
>>>>> Les "recipient" groupes ne sont qu'une facilité de définition et
>>>>> d'administration des utilisateurs et de leurs roles .
>>>>>

>>>>>> C'est là mon problème : je suis bien reconnu lors de
>>>>>> l'authentification CAS, mais lorsque j'affiche le profil dans
>>>>>> l'interface si l'uid est correct je n'ai aucune autre
>>>>>> information, je n'appartiens à aucun groupe et je n'ai donc
>>>>>> aucune autorisation. Le filtre que j'utilise dans
>>>>>> commons-parameters.properties pour
>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid). Pour les
>>>>>> autres paramètres c'est similaire.

>>>>> Le seul groupe par défaut est "all" . L'utilisateur doit en
>>>>> faire partie , sinon il ne pourra rien faire .
>>>>> Par défaut, toutes les entrées ldap de classes Person (ie tous les
>>>>> utilisateurs) en font partie :
>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>

>>>>>> J'ignore totalement pourquoi ça ne fonctionnement pas, me faut il
>>>>>> modifier des fichies ACEGI ?

>>>>> En général, dès que l'on modifie les droits: persmissions ou roles
>>>>> (en gros, dès que l'on touche à acegi-acls-root.xml, il faut faire :
>>>>> ant update-acls

>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de réponse, ou
>>>>>> alors j'ai du passer à côté, si c'est le cas veuillez m'excuser.
>>>>>> Merci pour votre aide.
>>>>>>

>>>>>
>>>>> Je ne suis pas sûr de répondre complètement à la question, car je
>>>>> ne connais pas ta configuration.
>>>>>
>>>>> Henri

>>>>
>>>>

>>>

>>
>>

>

> Re-bonjour Yannis,
>
> As-tu la possibilité de tester tes filtres avec un browser ldap ?
>
> Henri
> Yannis Roualdes a écrit :

>> Re-bonjour tout le monde,
>>
>> Me re-voila avec toujours le même problème. J'ai mis les filtres les
>> moins contraignant au niveau des groupes additionnels (uid=*) pour
>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL, et des filtres du style
>> (objectClass=*) pour WORKFLOW_LDAP_PEOPLE_FILTER. Alors que
>> l'authentification CAS se passe très bien je n'arrive toujours pas à
>> appartenir à un groupe.
>> Est ce que d'autres personnes ont été confrontées au même problème,
>> si oui comme a t il été résolu ?
>>
>> Bien à vous.
>>
>> Henri Jacob a écrit :

>>> Je ne vois rien d'incorrect.
>>> Le problème vient surement d'une mauvaise définition des groupes
>>> additionnels .
>>> Il faut vérifier la valeur des paramètres :
>>> ldap.virtualgroup.filter.all, ldap.virtualgroup.filter.moderators,
>>> ldap.virtualgroup.filter.admins
>>> Le mapping ldap est sans doute erroné.
>>>
>>> Désolé de ne pas pouvoir faire plus.
>>> Henri
>>>
>>> Yannis Roualdes a écrit :

>>>> Bonjour,
>>>>
>>>> Excusez moi pour cette réponse tardive, en pièce jointe vous
>>>> trouverez l'archive de ces fichiers. Il est possible que le
>>>> problème vienne des intitulés des propriétés utilisé dans notre
>>>> annuaire, je teste en ce moment même.
>>>> Cordialement.
>>>>
>>>> Henri Jacob a écrit :

>>>>> Bonjour,
>>>>>
>>>>> est-il possible de voir la config locale, au moins les fichiers :
>>>>> commons-parameters.properties
>>>>> conf/properties/spring/spring-categories.xml
>>>>> conf/properties/spring/spring-metadata-types.xml
>>>>> conf/propertiesspring/acegi/acegi-*.xml
>>>>>
>>>>> Henri
>>>>>
>>>>> Yannis Roualdes a écrit :

>>>>>> Bonjour,
>>>>>>
>>>>>> Merci pour cette réponse, elle confirme qu'il n'est pas
>>>>>> nécessaire de créer des groupes LDAP spécifiques à ORI-OAI, cela
>>>>>> m'arrange.
>>>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs tests et
>>>>>> quelque soit le filtre WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand
>>>>>> je me connecte je ne fais partie d'aucun groupe. J'ai bien
>>>>>> spécifié l'intitulé exact de l'objectClass pour le personnel de
>>>>>> notre établissement. En fait je ne vois pas où j'ai pu me tromper
>>>>>> c'est pourquoi je bloque.
>>>>>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL soit égal
>>>>>> à (objectClass=Person) ou à (uid=moniud) ça ne marche pas.
>>>>>> Bonne journée.
>>>>>>
>>>>>> Henri Jacob a écrit :

>>>>>>> Bonjour Yannis,
>>>>>>>
>>>>>>> Je réponds dans le message
>>>>>>>
>>>>>>> Yannis Roualdes wrote:

>>>>>>>> Bonjour à tous,
>>>>>>>>
>>>>>>>> Cette question vous paraîtra peut être stupide mais je
>>>>>>>> découvre LDAP (et ses filtres).
>>>>>>>> Premièrement il me semble, mais détrompez moi s'il le faut,
>>>>>>>> qu'il n'est pas nécessaire d'avoir des groupes LDAP
>>>>>>>> scpécifiques pour utiliser le workflow, si j'ai bien compris on
>>>>>>>> peut tout à fait gérer ces groupes avec les paramètres LDAP du
>>>>>>>> workflow.

>>>>>>> Dans le workflow, le terme acegi "recipient" représente soit un
>>>>>>> utilisateur, soit un groupe d'utilisateurs , soit un role. On
>>>>>>> peut donc en effet se passer de la notion de groupe
>>>>>>> d'utilisateurs. On peut par exemple attribuer le role
>>>>>>> "MODERATOR" directement à plusieurs utilisateurs.
>>>>>>>
>>>>>>> Les "recipient" groupes ne sont qu'une facilité de définition
>>>>>>> et d'administration des utilisateurs et de leurs roles .
>>>>>>>

>>>>>>>> C'est là mon problème : je suis bien reconnu lors de
>>>>>>>> l'authentification CAS, mais lorsque j'affiche le profil dans
>>>>>>>> l'interface si l'uid est correct je n'ai aucune autre
>>>>>>>> information, je n'appartiens à aucun groupe et je n'ai donc
>>>>>>>> aucune autorisation. Le filtre que j'utilise dans
>>>>>>>> commons-parameters.properties pour
>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid). Pour les
>>>>>>>> autres paramètres c'est similaire.

>>>>>>> Le seul groupe par défaut est "all" . L'utilisateur doit en
>>>>>>> faire partie , sinon il ne pourra rien faire .
>>>>>>> Par défaut, toutes les entrées ldap de classes Person (ie tous
>>>>>>> les utilisateurs) en font partie :
>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>>>

>>>>>>>> J'ignore totalement pourquoi ça ne fonctionnement pas, me faut
>>>>>>>> il modifier des fichies ACEGI ?

>>>>>>> En général, dès que l'on modifie les droits: persmissions ou
>>>>>>> roles (en gros, dès que l'on touche à acegi-acls-root.xml, il
>>>>>>> faut faire :
>>>>>>> ant update-acls

>>>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de réponse, ou
>>>>>>>> alors j'ai du passer à côté, si c'est le cas veuillez m'excuser.
>>>>>>>> Merci pour votre aide.
>>>>>>>>

>>>>>>>
>>>>>>> Je ne suis pas sûr de répondre complètement à la question, car
>>>>>>> je ne connais pas ta configuration.
>>>>>>>
>>>>>>> Henri

>>>>>>
>>>>>>

>>>>>

>>>>
>>>>

>>>

>>
>>

>

> Re-bonjour Yannis,
>
> As-tu la possibilité de tester tes filtres avec un browser ldap ?
>
> Henri
> Yannis Roualdes a écrit :

>> Re-bonjour tout le monde,
>>
>> Me re-voila avec toujours le même problème. J'ai mis les filtres les
>> moins contraignant au niveau des groupes additionnels (uid=*) pour
>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL, et des filtres du style
>> (objectClass=*) pour WORKFLOW_LDAP_PEOPLE_FILTER. Alors que
>> l'authentification CAS se passe très bien je n'arrive toujours pas à
>> appartenir à un groupe.
>> Est ce que d'autres personnes ont été confrontées au même problème,
>> si oui comme a t il été résolu ?
>>
>> Bien à vous.
>>
>> Henri Jacob a écrit :

>>> Je ne vois rien d'incorrect.
>>> Le problème vient surement d'une mauvaise définition des groupes
>>> additionnels .
>>> Il faut vérifier la valeur des paramètres :
>>> ldap.virtualgroup.filter.all, ldap.virtualgroup.filter.moderators,
>>> ldap.virtualgroup.filter.admins
>>> Le mapping ldap est sans doute erroné.
>>>
>>> Désolé de ne pas pouvoir faire plus.
>>> Henri
>>>
>>> Yannis Roualdes a écrit :

>>>> Bonjour,
>>>>
>>>> Excusez moi pour cette réponse tardive, en pièce jointe vous
>>>> trouverez l'archive de ces fichiers. Il est possible que le
>>>> problème vienne des intitulés des propriétés utilisé dans notre
>>>> annuaire, je teste en ce moment même.
>>>> Cordialement.
>>>>
>>>> Henri Jacob a écrit :

>>>>> Bonjour,
>>>>>
>>>>> est-il possible de voir la config locale, au moins les fichiers :
>>>>> commons-parameters.properties
>>>>> conf/properties/spring/spring-categories.xml
>>>>> conf/properties/spring/spring-metadata-types.xml
>>>>> conf/propertiesspring/acegi/acegi-*.xml
>>>>>
>>>>> Henri
>>>>>
>>>>> Yannis Roualdes a écrit :

>>>>>> Bonjour,
>>>>>>
>>>>>> Merci pour cette réponse, elle confirme qu'il n'est pas
>>>>>> nécessaire de créer des groupes LDAP spécifiques à ORI-OAI, cela
>>>>>> m'arrange.
>>>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs tests et
>>>>>> quelque soit le filtre WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand
>>>>>> je me connecte je ne fais partie d'aucun groupe. J'ai bien
>>>>>> spécifié l'intitulé exact de l'objectClass pour le personnel de
>>>>>> notre établissement. En fait je ne vois pas où j'ai pu me tromper
>>>>>> c'est pourquoi je bloque.
>>>>>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL soit égal
>>>>>> à (objectClass=Person) ou à (uid=moniud) ça ne marche pas.
>>>>>> Bonne journée.
>>>>>>
>>>>>> Henri Jacob a écrit :

>>>>>>> Bonjour Yannis,
>>>>>>>
>>>>>>> Je réponds dans le message
>>>>>>>
>>>>>>> Yannis Roualdes wrote:

>>>>>>>> Bonjour à tous,
>>>>>>>>
>>>>>>>> Cette question vous paraîtra peut être stupide mais je
>>>>>>>> découvre LDAP (et ses filtres).
>>>>>>>> Premièrement il me semble, mais détrompez moi s'il le faut,
>>>>>>>> qu'il n'est pas nécessaire d'avoir des groupes LDAP
>>>>>>>> scpécifiques pour utiliser le workflow, si j'ai bien compris on
>>>>>>>> peut tout à fait gérer ces groupes avec les paramètres LDAP du
>>>>>>>> workflow.

>>>>>>> Dans le workflow, le terme acegi "recipient" représente soit un
>>>>>>> utilisateur, soit un groupe d'utilisateurs , soit un role. On
>>>>>>> peut donc en effet se passer de la notion de groupe
>>>>>>> d'utilisateurs. On peut par exemple attribuer le role
>>>>>>> "MODERATOR" directement à plusieurs utilisateurs.
>>>>>>>
>>>>>>> Les "recipient" groupes ne sont qu'une facilité de définition
>>>>>>> et d'administration des utilisateurs et de leurs roles .
>>>>>>>

>>>>>>>> C'est là mon problème : je suis bien reconnu lors de
>>>>>>>> l'authentification CAS, mais lorsque j'affiche le profil dans
>>>>>>>> l'interface si l'uid est correct je n'ai aucune autre
>>>>>>>> information, je n'appartiens à aucun groupe et je n'ai donc
>>>>>>>> aucune autorisation. Le filtre que j'utilise dans
>>>>>>>> commons-parameters.properties pour
>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid). Pour les
>>>>>>>> autres paramètres c'est similaire.

>>>>>>> Le seul groupe par défaut est "all" . L'utilisateur doit en
>>>>>>> faire partie , sinon il ne pourra rien faire .
>>>>>>> Par défaut, toutes les entrées ldap de classes Person (ie tous
>>>>>>> les utilisateurs) en font partie :
>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>>>

>>>>>>>> J'ignore totalement pourquoi ça ne fonctionnement pas, me faut
>>>>>>>> il modifier des fichies ACEGI ?

>>>>>>> En général, dès que l'on modifie les droits: persmissions ou
>>>>>>> roles (en gros, dès que l'on touche à acegi-acls-root.xml, il
>>>>>>> faut faire :
>>>>>>> ant update-acls

>>>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de réponse, ou
>>>>>>>> alors j'ai du passer à côté, si c'est le cas veuillez m'excuser.
>>>>>>>> Merci pour votre aide.
>>>>>>>>

>>>>>>>
>>>>>>> Je ne suis pas sûr de répondre complètement à la question, car
>>>>>>> je ne connais pas ta configuration.
>>>>>>>
>>>>>>> Henri

>>>>>>
>>>>>>

>>>>>

>>>>
>>>>

>>>

>>
>>

>

> Bonjour Yannis,
>
> Est-ce que tu peux envoyer ton fichier commons-parameters.properties
> stp ? N'oublie pas de masquer les mots de passe.
>
> Merci
> Yohan
>
> Yannis Roualdes a écrit :

>> Re-bonjour,
>>
>> J'ai pu avoir accès aux logs des communications entre ORI-OAI et
>> l'annuaire LDAP de mon établissement, ceci uniquement pour le login
>> puisque c'est ce qui pose problème. Le seul souci que j'ai pu noter
>> est qu'un filtre portant sur la recherche de groupe ne renvoie rien.
>> Par contre les filtres des groupes additionnels fonctionnent
>> correctement. Est ce le problème ? Sachant que je n'utilise pas de
>> groupes spécifiques à ORI-OAI, uniquement les groupes additionnels.
>> Par ailleurs j'ai modifié le log4j.properties du workflow pour avoir
>> les logs acegi, mais même en mettant INFO je n'ai pas le détails des
>> requêtes et réponses, y a t il des paramètres particuliers ?
>>
>> Cordialement.
>>
>> Henri Jacob a écrit :

>>> Re-bonjour Yannis,
>>>
>>> As-tu la possibilité de tester tes filtres avec un browser ldap ?
>>>
>>> Henri
>>> Yannis Roualdes a écrit :

>>>> Re-bonjour tout le monde,
>>>>
>>>> Me re-voila avec toujours le même problème. J'ai mis les filtres
>>>> les moins contraignant au niveau des groupes additionnels (uid=*)
>>>> pour WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL, et des filtres du style
>>>> (objectClass=*) pour WORKFLOW_LDAP_PEOPLE_FILTER. Alors que
>>>> l'authentification CAS se passe très bien je n'arrive toujours pas
>>>> à appartenir à un groupe.
>>>> Est ce que d'autres personnes ont été confrontées au même problème,
>>>> si oui comme a t il été résolu ?
>>>>
>>>> Bien à vous.
>>>>
>>>> Henri Jacob a écrit :

>>>>> Je ne vois rien d'incorrect.
>>>>> Le problème vient surement d'une mauvaise définition des groupes
>>>>> additionnels .
>>>>> Il faut vérifier la valeur des paramètres :
>>>>> ldap.virtualgroup.filter.all, ldap.virtualgroup.filter.moderators,
>>>>> ldap.virtualgroup.filter.admins
>>>>> Le mapping ldap est sans doute erroné.
>>>>>
>>>>> Désolé de ne pas pouvoir faire plus.
>>>>> Henri
>>>>>
>>>>> Yannis Roualdes a écrit :

>>>>>> Bonjour,
>>>>>>
>>>>>> Excusez moi pour cette réponse tardive, en pièce jointe vous
>>>>>> trouverez l'archive de ces fichiers. Il est possible que le
>>>>>> problème vienne des intitulés des propriétés utilisé dans notre
>>>>>> annuaire, je teste en ce moment même.
>>>>>> Cordialement.
>>>>>>
>>>>>> Henri Jacob a écrit :

>>>>>>> Bonjour,
>>>>>>>
>>>>>>> est-il possible de voir la config locale, au moins les fichiers :
>>>>>>> commons-parameters.properties
>>>>>>> conf/properties/spring/spring-categories.xml
>>>>>>> conf/properties/spring/spring-metadata-types.xml
>>>>>>> conf/propertiesspring/acegi/acegi-*.xml
>>>>>>>
>>>>>>> Henri
>>>>>>>
>>>>>>> Yannis Roualdes a écrit :

>>>>>>>> Bonjour,
>>>>>>>>
>>>>>>>> Merci pour cette réponse, elle confirme qu'il n'est pas
>>>>>>>> nécessaire de créer des groupes LDAP spécifiques à ORI-OAI,
>>>>>>>> cela m'arrange.
>>>>>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs tests et
>>>>>>>> quelque soit le filtre WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL
>>>>>>>> quand je me connecte je ne fais partie d'aucun groupe. J'ai
>>>>>>>> bien spécifié l'intitulé exact de l'objectClass pour le
>>>>>>>> personnel de notre établissement. En fait je ne vois pas où
>>>>>>>> j'ai pu me tromper c'est pourquoi je bloque.
>>>>>>>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL soit
>>>>>>>> égal à (objectClass=Person) ou à (uid=moniud) ça ne marche pas.
>>>>>>>> Bonne journée.
>>>>>>>>
>>>>>>>> Henri Jacob a écrit :

>>>>>>>>> Bonjour Yannis,
>>>>>>>>>
>>>>>>>>> Je réponds dans le message
>>>>>>>>>
>>>>>>>>> Yannis Roualdes wrote:

>>>>>>>>>> Bonjour à tous,
>>>>>>>>>>
>>>>>>>>>> Cette question vous paraîtra peut être stupide mais je
>>>>>>>>>> découvre LDAP (et ses filtres).
>>>>>>>>>> Premièrement il me semble, mais détrompez moi s'il le faut,
>>>>>>>>>> qu'il n'est pas nécessaire d'avoir des groupes LDAP
>>>>>>>>>> scpécifiques pour utiliser le workflow, si j'ai bien compris
>>>>>>>>>> on peut tout à fait gérer ces groupes avec les paramètres
>>>>>>>>>> LDAP du workflow.

>>>>>>>>> Dans le workflow, le terme acegi "recipient" représente soit
>>>>>>>>> un utilisateur, soit un groupe d'utilisateurs , soit un role.
>>>>>>>>> On peut donc en effet se passer de la notion de groupe
>>>>>>>>> d'utilisateurs. On peut par exemple attribuer le role
>>>>>>>>> "MODERATOR" directement à plusieurs utilisateurs.
>>>>>>>>>
>>>>>>>>> Les "recipient" groupes ne sont qu'une facilité de définition
>>>>>>>>> et d'administration des utilisateurs et de leurs roles .
>>>>>>>>>

>>>>>>>>>> C'est là mon problème : je suis bien reconnu lors de
>>>>>>>>>> l'authentification CAS, mais lorsque j'affiche le profil dans
>>>>>>>>>> l'interface si l'uid est correct je n'ai aucune autre
>>>>>>>>>> information, je n'appartiens à aucun groupe et je n'ai donc
>>>>>>>>>> aucune autorisation. Le filtre que j'utilise dans
>>>>>>>>>> commons-parameters.properties pour
>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid). Pour
>>>>>>>>>> les autres paramètres c'est similaire.

>>>>>>>>> Le seul groupe par défaut est "all" . L'utilisateur doit en
>>>>>>>>> faire partie , sinon il ne pourra rien faire .
>>>>>>>>> Par défaut, toutes les entrées ldap de classes Person (ie tous
>>>>>>>>> les utilisateurs) en font partie :
>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>>>>>

>>>>>>>>>> J'ignore totalement pourquoi ça ne fonctionnement pas, me
>>>>>>>>>> faut il modifier des fichies ACEGI ?

>>>>>>>>> En général, dès que l'on modifie les droits: persmissions ou
>>>>>>>>> roles (en gros, dès que l'on touche à acegi-acls-root.xml, il
>>>>>>>>> faut faire :
>>>>>>>>> ant update-acls

>>>>>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de réponse,
>>>>>>>>>> ou alors j'ai du passer à côté, si c'est le cas veuillez
>>>>>>>>>> m'excuser.
>>>>>>>>>> Merci pour votre aide.
>>>>>>>>>>

>>>>>>>>>
>>>>>>>>> Je ne suis pas sûr de répondre complètement à la question, car
>>>>>>>>> je ne connais pas ta configuration.
>>>>>>>>>
>>>>>>>>> Henri

>>>>>>>>
>>>>>>>>

>>>>>>>

>>>>>>
>>>>>>

>>>>>

>>>>
>>>>

>>>

>>
>>

>
> --
> Ce message a été vérifié par
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.

> Bonjour Yannis,
>
> Peux-tu vérifier certaines choses par rapport à ton LDAP stp ?
>
> - "uidInterne=roualdes,ou=People,dc=upmc,dc=fr" (avec majuscule) est
> bien une branche de ton LDAP ?
>
> - "(objectClass=personnel)" renvoie bien des entrées ?
>
> - quelle différence ça fait si tu changes l'attribut suivant en :
> "WORKFLOW_LDAP_PEOPLE_UID_ATTRIBUTE=uidInterne" ?
>
> - idem pour
> "WORKFLOW_ACEGI_ADD_GROUPS_FILTER_MODERATORS=(uidInterne=roualdes)"
>
> Aussi, quand tu te connectes avec n'importe quel compte personnel,
> est-ce que tu arrives à éditer une fiche pédagogique ? Si oui, tu fais
> partie du groupe ALL, donc (objectClass=personnel) est ok
> Si tu arrives bien à éditer cette fiche, quand tu demandes la
> publication et que tu te connectes avec ton compte "roualdes" c'est là
> que tu n'as pas le dossier virtuel "Ressources que je dois modérer" ?
>
> Merci
> Yohan
>
> Yannis Roualdes a écrit :

>> Bonjour Yohann et Vincent,
>>
>> Premièrement vous ne pouvez pas savoir à quel point ça me chagrine de
>> vous solliciter à ce point.
>> Veuillez trouver en pièce jointe le fichier
>> commons-parameters.properties.
>> Pour ce qui est des logs je me suis peut être trompé dans les
>> paramètres, je vais fouiller un peu plus, j'arriverai peut être à
>> avoir quelques informations supplémentaires.
>>
>> Pour expliquer un peu les paramètres du fichier il faut savoir que
>> notre annuaire possède un uid et un uidInterne, en fait
>> l'authentification utilise l'uidInterne.
>>
>> PS1 : désolé pour la réponse tardive
>>
>> Yohan Colmant a écrit :

>>> Bonjour Yannis,
>>>
>>> Est-ce que tu peux envoyer ton fichier commons-parameters.properties
>>> stp ? N'oublie pas de masquer les mots de passe.
>>>
>>> Merci
>>> Yohan
>>>
>>> Yannis Roualdes a écrit :

>>>> Re-bonjour,
>>>>
>>>> J'ai pu avoir accès aux logs des communications entre ORI-OAI et
>>>> l'annuaire LDAP de mon établissement, ceci uniquement pour le login
>>>> puisque c'est ce qui pose problème. Le seul souci que j'ai pu noter
>>>> est qu'un filtre portant sur la recherche de groupe ne renvoie
>>>> rien. Par contre les filtres des groupes additionnels fonctionnent
>>>> correctement. Est ce le problème ? Sachant que je n'utilise pas de
>>>> groupes spécifiques à ORI-OAI, uniquement les groupes additionnels.
>>>> Par ailleurs j'ai modifié le log4j.properties du workflow pour
>>>> avoir les logs acegi, mais même en mettant INFO je n'ai pas le
>>>> détails des requêtes et réponses, y a t il des paramètres
>>>> particuliers ?
>>>>
>>>> Cordialement.
>>>>
>>>> Henri Jacob a écrit :

>>>>> Re-bonjour Yannis,
>>>>>
>>>>> As-tu la possibilité de tester tes filtres avec un browser ldap ?
>>>>>
>>>>> Henri
>>>>> Yannis Roualdes a écrit :

>>>>>> Re-bonjour tout le monde,
>>>>>>
>>>>>> Me re-voila avec toujours le même problème. J'ai mis les filtres
>>>>>> les moins contraignant au niveau des groupes additionnels (uid=*)
>>>>>> pour WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL, et des filtres du
>>>>>> style (objectClass=*) pour WORKFLOW_LDAP_PEOPLE_FILTER. Alors que
>>>>>> l'authentification CAS se passe très bien je n'arrive toujours
>>>>>> pas à appartenir à un groupe.
>>>>>> Est ce que d'autres personnes ont été confrontées au même
>>>>>> problème, si oui comme a t il été résolu ?
>>>>>>
>>>>>> Bien à vous.
>>>>>>
>>>>>> Henri Jacob a écrit :

>>>>>>> Je ne vois rien d'incorrect.
>>>>>>> Le problème vient surement d'une mauvaise définition des groupes
>>>>>>> additionnels .
>>>>>>> Il faut vérifier la valeur des paramètres :
>>>>>>> ldap.virtualgroup.filter.all,
>>>>>>> ldap.virtualgroup.filter.moderators,
>>>>>>> ldap.virtualgroup.filter.admins
>>>>>>> Le mapping ldap est sans doute erroné.
>>>>>>>
>>>>>>> Désolé de ne pas pouvoir faire plus.
>>>>>>> Henri
>>>>>>>
>>>>>>> Yannis Roualdes a écrit :

>>>>>>>> Bonjour,
>>>>>>>>
>>>>>>>> Excusez moi pour cette réponse tardive, en pièce jointe vous
>>>>>>>> trouverez l'archive de ces fichiers. Il est possible que le
>>>>>>>> problème vienne des intitulés des propriétés utilisé dans notre
>>>>>>>> annuaire, je teste en ce moment même.
>>>>>>>> Cordialement.
>>>>>>>>
>>>>>>>> Henri Jacob a écrit :

>>>>>>>>> Bonjour,
>>>>>>>>>
>>>>>>>>> est-il possible de voir la config locale, au moins les fichiers :
>>>>>>>>> commons-parameters.properties
>>>>>>>>> conf/properties/spring/spring-categories.xml
>>>>>>>>> conf/properties/spring/spring-metadata-types.xml
>>>>>>>>> conf/propertiesspring/acegi/acegi-*.xml
>>>>>>>>>
>>>>>>>>> Henri
>>>>>>>>>
>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>> Bonjour,
>>>>>>>>>>
>>>>>>>>>> Merci pour cette réponse, elle confirme qu'il n'est pas
>>>>>>>>>> nécessaire de créer des groupes LDAP spécifiques à ORI-OAI,
>>>>>>>>>> cela m'arrange.
>>>>>>>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs tests
>>>>>>>>>> et quelque soit le filtre
>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand je me connecte je
>>>>>>>>>> ne fais partie d'aucun groupe. J'ai bien spécifié l'intitulé
>>>>>>>>>> exact de l'objectClass pour le personnel de notre
>>>>>>>>>> établissement. En fait je ne vois pas où j'ai pu me tromper
>>>>>>>>>> c'est pourquoi je bloque.
>>>>>>>>>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL soit
>>>>>>>>>> égal à (objectClass=Person) ou à (uid=moniud) ça ne marche pas.
>>>>>>>>>> Bonne journée.
>>>>>>>>>>
>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>> Bonjour Yannis,
>>>>>>>>>>>
>>>>>>>>>>> Je réponds dans le message
>>>>>>>>>>>
>>>>>>>>>>> Yannis Roualdes wrote:

>>>>>>>>>>>> Bonjour à tous,
>>>>>>>>>>>>
>>>>>>>>>>>> Cette question vous paraîtra peut être stupide mais je
>>>>>>>>>>>> découvre LDAP (et ses filtres).
>>>>>>>>>>>> Premièrement il me semble, mais détrompez moi s'il le faut,
>>>>>>>>>>>> qu'il n'est pas nécessaire d'avoir des groupes LDAP
>>>>>>>>>>>> scpécifiques pour utiliser le workflow, si j'ai bien
>>>>>>>>>>>> compris on peut tout à fait gérer ces groupes avec les
>>>>>>>>>>>> paramètres LDAP du workflow.

>>>>>>>>>>> Dans le workflow, le terme acegi "recipient" représente soit
>>>>>>>>>>> un utilisateur, soit un groupe d'utilisateurs , soit un
>>>>>>>>>>> role. On peut donc en effet se passer de la notion de groupe
>>>>>>>>>>> d'utilisateurs. On peut par exemple attribuer le role
>>>>>>>>>>> "MODERATOR" directement à plusieurs utilisateurs.
>>>>>>>>>>>
>>>>>>>>>>> Les "recipient" groupes ne sont qu'une facilité de
>>>>>>>>>>> définition et d'administration des utilisateurs et de leurs
>>>>>>>>>>> roles .
>>>>>>>>>>>

>>>>>>>>>>>> C'est là mon problème : je suis bien reconnu lors de
>>>>>>>>>>>> l'authentification CAS, mais lorsque j'affiche le profil
>>>>>>>>>>>> dans l'interface si l'uid est correct je n'ai aucune autre
>>>>>>>>>>>> information, je n'appartiens à aucun groupe et je n'ai donc
>>>>>>>>>>>> aucune autorisation. Le filtre que j'utilise dans
>>>>>>>>>>>> commons-parameters.properties pour
>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid). Pour
>>>>>>>>>>>> les autres paramètres c'est similaire.

>>>>>>>>>>> Le seul groupe par défaut est "all" . L'utilisateur doit
>>>>>>>>>>> en faire partie , sinon il ne pourra rien faire .
>>>>>>>>>>> Par défaut, toutes les entrées ldap de classes Person (ie
>>>>>>>>>>> tous les utilisateurs) en font partie :
>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>>>>>>>

>>>>>>>>>>>> J'ignore totalement pourquoi ça ne fonctionnement pas, me
>>>>>>>>>>>> faut il modifier des fichies ACEGI ?

>>>>>>>>>>> En général, dès que l'on modifie les droits: persmissions ou
>>>>>>>>>>> roles (en gros, dès que l'on touche à acegi-acls-root.xml,
>>>>>>>>>>> il faut faire :
>>>>>>>>>>> ant update-acls

>>>>>>>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de réponse,
>>>>>>>>>>>> ou alors j'ai du passer à côté, si c'est le cas veuillez
>>>>>>>>>>>> m'excuser.
>>>>>>>>>>>> Merci pour votre aide.
>>>>>>>>>>>>

>>>>>>>>>>>
>>>>>>>>>>> Je ne suis pas sûr de répondre complètement à la question,
>>>>>>>>>>> car je ne connais pas ta configuration.
>>>>>>>>>>>
>>>>>>>>>>> Henri

>>>>>>>>>>
>>>>>>>>>>

>>>>>>>>>

>>>>>>>>
>>>>>>>>

>>>>>>>

>>>>>>
>>>>>>

>>>>>

>>>>
>>>>

>>>
>>> --
>>> Ce message a été vérifié par
>>> pour des virus ou des polluriels et rien de
>>> suspect n'a été trouvé.

>>
>>

>
> --
> Ce message a été vérifié par
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.

> Merci Yannis pour ces points.
> Si tu mets ceci:
>
> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(uid=roualdes)
>
> ça devrait te permettre d'initier un workflow. Tu as déjà essayé ? Si
> ça marche, le problème peut effectivement venir de la limite de
> (objectClass=personnel)
>
> Yohan
>
>
>
> Yannis Roualdes a écrit :

>> Bonjour Yohann,
>>
>> "uidInterne=roualdes,ou=People,dc=upmc,dc=fr" est bien une branche
>> pour autant que je puisse en juger (ldapsearch me renvoie les bonnes
>> données).
>>
>> "(objectClass=personnel)" sans autre restriction renvoie des données
>> mais de manière incomplète : la taille limite est atteinte assez
>> rapidement, donc il n'y pas les données de l'ensemble des personnes
>> concernées par ce filtre.
>>
>> Il n'y a aucune différence lorsque je modifie
>> WORKFLOW_LDAP_PEOPLE_UID_ATTRIBUTE et
>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_MODERATORS.
>>
>> Pour le moment lorsque je me connecte je peux créer une nouvelle
>> fiche mais pas la sauvegarder (je n'ai pas les droits d'initier un
>> workflow). Le souci vient peut être du fait que
>> (objectClass=personnel) ne renvoie que des données partielles du à la
>> limite de taille de la réponse.
>>
>> Voila tout ce que je peux dire pour le moment.
>>
>> En tout cas merci pour ton aide.
>>
>>
>> Yohan Colmant a écrit :

>>> Bonjour Yannis,
>>>
>>> Peux-tu vérifier certaines choses par rapport à ton LDAP stp ?
>>>
>>> - "uidInterne=roualdes,ou=People,dc=upmc,dc=fr" (avec majuscule) est
>>> bien une branche de ton LDAP ?
>>>
>>> - "(objectClass=personnel)" renvoie bien des entrées ?
>>>
>>> - quelle différence ça fait si tu changes l'attribut suivant en :
>>> "WORKFLOW_LDAP_PEOPLE_UID_ATTRIBUTE=uidInterne" ?
>>>
>>> - idem pour
>>> "WORKFLOW_ACEGI_ADD_GROUPS_FILTER_MODERATORS=(uidInterne=roualdes)"
>>>
>>> Aussi, quand tu te connectes avec n'importe quel compte personnel,
>>> est-ce que tu arrives à éditer une fiche pédagogique ? Si oui, tu
>>> fais partie du groupe ALL, donc (objectClass=personnel) est ok
>>> Si tu arrives bien à éditer cette fiche, quand tu demandes la
>>> publication et que tu te connectes avec ton compte "roualdes" c'est
>>> là que tu n'as pas le dossier virtuel "Ressources que je dois
>>> modérer" ?
>>>
>>> Merci
>>> Yohan
>>>
>>> Yannis Roualdes a écrit :

>>>> Bonjour Yohann et Vincent,
>>>>
>>>> Premièrement vous ne pouvez pas savoir à quel point ça me chagrine
>>>> de vous solliciter à ce point.
>>>> Veuillez trouver en pièce jointe le fichier
>>>> commons-parameters.properties.
>>>> Pour ce qui est des logs je me suis peut être trompé dans les
>>>> paramètres, je vais fouiller un peu plus, j'arriverai peut être à
>>>> avoir quelques informations supplémentaires.
>>>>
>>>> Pour expliquer un peu les paramètres du fichier il faut savoir que
>>>> notre annuaire possède un uid et un uidInterne, en fait
>>>> l'authentification utilise l'uidInterne.
>>>>
>>>> PS1 : désolé pour la réponse tardive
>>>>
>>>> Yohan Colmant a écrit :

>>>>> Bonjour Yannis,
>>>>>
>>>>> Est-ce que tu peux envoyer ton fichier
>>>>> commons-parameters.properties stp ? N'oublie pas de masquer les
>>>>> mots de passe.
>>>>>
>>>>> Merci
>>>>> Yohan
>>>>>
>>>>> Yannis Roualdes a écrit :

>>>>>> Re-bonjour,
>>>>>>
>>>>>> J'ai pu avoir accès aux logs des communications entre ORI-OAI et
>>>>>> l'annuaire LDAP de mon établissement, ceci uniquement pour le
>>>>>> login puisque c'est ce qui pose problème. Le seul souci que j'ai
>>>>>> pu noter est qu'un filtre portant sur la recherche de groupe ne
>>>>>> renvoie rien. Par contre les filtres des groupes additionnels
>>>>>> fonctionnent correctement. Est ce le problème ? Sachant que je
>>>>>> n'utilise pas de groupes spécifiques à ORI-OAI, uniquement les
>>>>>> groupes additionnels.
>>>>>> Par ailleurs j'ai modifié le log4j.properties du workflow pour
>>>>>> avoir les logs acegi, mais même en mettant INFO je n'ai pas le
>>>>>> détails des requêtes et réponses, y a t il des paramètres
>>>>>> particuliers ?
>>>>>>
>>>>>> Cordialement.
>>>>>>
>>>>>> Henri Jacob a écrit :

>>>>>>> Re-bonjour Yannis,
>>>>>>>
>>>>>>> As-tu la possibilité de tester tes filtres avec un browser ldap ?
>>>>>>>
>>>>>>> Henri
>>>>>>> Yannis Roualdes a écrit :

>>>>>>>> Re-bonjour tout le monde,
>>>>>>>>
>>>>>>>> Me re-voila avec toujours le même problème. J'ai mis les
>>>>>>>> filtres les moins contraignant au niveau des groupes
>>>>>>>> additionnels (uid=*) pour WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL,
>>>>>>>> et des filtres du style (objectClass=*) pour
>>>>>>>> WORKFLOW_LDAP_PEOPLE_FILTER. Alors que l'authentification CAS
>>>>>>>> se passe très bien je n'arrive toujours pas à appartenir à un
>>>>>>>> groupe.
>>>>>>>> Est ce que d'autres personnes ont été confrontées au même
>>>>>>>> problème, si oui comme a t il été résolu ?
>>>>>>>>
>>>>>>>> Bien à vous.
>>>>>>>>
>>>>>>>> Henri Jacob a écrit :

>>>>>>>>> Je ne vois rien d'incorrect.
>>>>>>>>> Le problème vient surement d'une mauvaise définition des
>>>>>>>>> groupes additionnels .
>>>>>>>>> Il faut vérifier la valeur des paramètres :
>>>>>>>>> ldap.virtualgroup.filter.all,
>>>>>>>>> ldap.virtualgroup.filter.moderators,
>>>>>>>>> ldap.virtualgroup.filter.admins
>>>>>>>>> Le mapping ldap est sans doute erroné.
>>>>>>>>>
>>>>>>>>> Désolé de ne pas pouvoir faire plus.
>>>>>>>>> Henri
>>>>>>>>>
>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>> Bonjour,
>>>>>>>>>>
>>>>>>>>>> Excusez moi pour cette réponse tardive, en pièce jointe vous
>>>>>>>>>> trouverez l'archive de ces fichiers. Il est possible que le
>>>>>>>>>> problème vienne des intitulés des propriétés utilisé dans
>>>>>>>>>> notre annuaire, je teste en ce moment même.
>>>>>>>>>> Cordialement.
>>>>>>>>>>
>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>> Bonjour,
>>>>>>>>>>>
>>>>>>>>>>> est-il possible de voir la config locale, au moins les
>>>>>>>>>>> fichiers :
>>>>>>>>>>> commons-parameters.properties
>>>>>>>>>>> conf/properties/spring/spring-categories.xml
>>>>>>>>>>> conf/properties/spring/spring-metadata-types.xml
>>>>>>>>>>> conf/propertiesspring/acegi/acegi-*.xml
>>>>>>>>>>>
>>>>>>>>>>> Henri
>>>>>>>>>>>
>>>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>>>> Bonjour,
>>>>>>>>>>>>
>>>>>>>>>>>> Merci pour cette réponse, elle confirme qu'il n'est pas
>>>>>>>>>>>> nécessaire de créer des groupes LDAP spécifiques à ORI-OAI,
>>>>>>>>>>>> cela m'arrange.
>>>>>>>>>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs
>>>>>>>>>>>> tests et quelque soit le filtre
>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand je me connecte
>>>>>>>>>>>> je ne fais partie d'aucun groupe. J'ai bien spécifié
>>>>>>>>>>>> l'intitulé exact de l'objectClass pour le personnel de
>>>>>>>>>>>> notre établissement. En fait je ne vois pas où j'ai pu me
>>>>>>>>>>>> tromper c'est pourquoi je bloque.
>>>>>>>>>>>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL
>>>>>>>>>>>> soit égal à (objectClass=Person) ou à (uid=moniud) ça ne
>>>>>>>>>>>> marche pas.
>>>>>>>>>>>> Bonne journée.
>>>>>>>>>>>>
>>>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>>>> Bonjour Yannis,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Je réponds dans le message
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yannis Roualdes wrote:

>>>>>>>>>>>>>> Bonjour à tous,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cette question vous paraîtra peut être stupide mais je
>>>>>>>>>>>>>> découvre LDAP (et ses filtres).
>>>>>>>>>>>>>> Premièrement il me semble, mais détrompez moi s'il le
>>>>>>>>>>>>>> faut, qu'il n'est pas nécessaire d'avoir des groupes LDAP
>>>>>>>>>>>>>> scpécifiques pour utiliser le workflow, si j'ai bien
>>>>>>>>>>>>>> compris on peut tout à fait gérer ces groupes avec les
>>>>>>>>>>>>>> paramètres LDAP du workflow.

>>>>>>>>>>>>> Dans le workflow, le terme acegi "recipient" représente
>>>>>>>>>>>>> soit un utilisateur, soit un groupe d'utilisateurs , soit
>>>>>>>>>>>>> un role. On peut donc en effet se passer de la notion de
>>>>>>>>>>>>> groupe d'utilisateurs. On peut par exemple attribuer le
>>>>>>>>>>>>> role "MODERATOR" directement à plusieurs utilisateurs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Les "recipient" groupes ne sont qu'une facilité de
>>>>>>>>>>>>> définition et d'administration des utilisateurs et de
>>>>>>>>>>>>> leurs roles .
>>>>>>>>>>>>>

>>>>>>>>>>>>>> C'est là mon problème : je suis bien reconnu lors de
>>>>>>>>>>>>>> l'authentification CAS, mais lorsque j'affiche le profil
>>>>>>>>>>>>>> dans l'interface si l'uid est correct je n'ai aucune
>>>>>>>>>>>>>> autre information, je n'appartiens à aucun groupe et je
>>>>>>>>>>>>>> n'ai donc aucune autorisation. Le filtre que j'utilise
>>>>>>>>>>>>>> dans commons-parameters.properties pour
>>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid).
>>>>>>>>>>>>>> Pour les autres paramètres c'est similaire.

>>>>>>>>>>>>> Le seul groupe par défaut est "all" . L'utilisateur
>>>>>>>>>>>>> doit en faire partie , sinon il ne pourra rien faire .
>>>>>>>>>>>>> Par défaut, toutes les entrées ldap de classes Person (ie
>>>>>>>>>>>>> tous les utilisateurs) en font partie :
>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>>>>>>>>>

>>>>>>>>>>>>>> J'ignore totalement pourquoi ça ne fonctionnement pas, me
>>>>>>>>>>>>>> faut il modifier des fichies ACEGI ?

>>>>>>>>>>>>> En général, dès que l'on modifie les droits: persmissions
>>>>>>>>>>>>> ou roles (en gros, dès que l'on touche à
>>>>>>>>>>>>> acegi-acls-root.xml, il faut faire :
>>>>>>>>>>>>> ant update-acls

>>>>>>>>>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de
>>>>>>>>>>>>>> réponse, ou alors j'ai du passer à côté, si c'est le cas
>>>>>>>>>>>>>> veuillez m'excuser.
>>>>>>>>>>>>>> Merci pour votre aide.
>>>>>>>>>>>>>>

>>>>>>>>>>>>>
>>>>>>>>>>>>> Je ne suis pas sûr de répondre complètement à la question,
>>>>>>>>>>>>> car je ne connais pas ta configuration.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Henri

>>>>>>>>>>>>
>>>>>>>>>>>>

>>>>>>>>>>>

>>>>>>>>>>
>>>>>>>>>>

>>>>>>>>>

>>>>>>>>
>>>>>>>>

>>>>>>>

>>>>>>
>>>>>>

>>>>>
>>>>> --
>>>>> Ce message a été vérifié par
>>>>> pour des virus ou des polluriels et rien de
>>>>> suspect n'a été trouvé.

>>>>
>>>>

>>>
>>> --
>>> Ce message a été vérifié par
>>> pour des virus ou des polluriels et rien de
>>> suspect n'a été trouvé.

>>
>>

>
> --
> Ce message a été vérifié par
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.

> Hélas j'avais déjà essayé, en fait j'ai testé beaucoup de combinaisons
> de filtres et je ne parviens pas à faire partie d'un groupe.
>
> Yohan Colmant a écrit :

>> Merci Yannis pour ces points.
>> Si tu mets ceci:
>>
>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(uid=roualdes)
>>
>> ça devrait te permettre d'initier un workflow. Tu as déjà essayé ? Si
>> ça marche, le problème peut effectivement venir de la limite de
>> (objectClass=personnel)
>>
>> Yohan
>>
>>
>>
>> Yannis Roualdes a écrit :

>>> Bonjour Yohann,
>>>
>>> "uidInterne=roualdes,ou=People,dc=upmc,dc=fr" est bien une branche
>>> pour autant que je puisse en juger (ldapsearch me renvoie les bonnes
>>> données).
>>>
>>> "(objectClass=personnel)" sans autre restriction renvoie des données
>>> mais de manière incomplète : la taille limite est atteinte assez
>>> rapidement, donc il n'y pas les données de l'ensemble des personnes
>>> concernées par ce filtre.
>>>
>>> Il n'y a aucune différence lorsque je modifie
>>> WORKFLOW_LDAP_PEOPLE_UID_ATTRIBUTE et
>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_MODERATORS.
>>>
>>> Pour le moment lorsque je me connecte je peux créer une nouvelle
>>> fiche mais pas la sauvegarder (je n'ai pas les droits d'initier un
>>> workflow). Le souci vient peut être du fait que
>>> (objectClass=personnel) ne renvoie que des données partielles du à
>>> la limite de taille de la réponse.
>>>
>>> Voila tout ce que je peux dire pour le moment.
>>>
>>> En tout cas merci pour ton aide.
>>>
>>>
>>> Yohan Colmant a écrit :

>>>> Bonjour Yannis,
>>>>
>>>> Peux-tu vérifier certaines choses par rapport à ton LDAP stp ?
>>>>
>>>> - "uidInterne=roualdes,ou=People,dc=upmc,dc=fr" (avec majuscule)
>>>> est bien une branche de ton LDAP ?
>>>>
>>>> - "(objectClass=personnel)" renvoie bien des entrées ?
>>>>
>>>> - quelle différence ça fait si tu changes l'attribut suivant en :
>>>> "WORKFLOW_LDAP_PEOPLE_UID_ATTRIBUTE=uidInterne" ?
>>>>
>>>> - idem pour
>>>> "WORKFLOW_ACEGI_ADD_GROUPS_FILTER_MODERATORS=(uidInterne=roualdes)"
>>>>
>>>> Aussi, quand tu te connectes avec n'importe quel compte personnel,
>>>> est-ce que tu arrives à éditer une fiche pédagogique ? Si oui, tu
>>>> fais partie du groupe ALL, donc (objectClass=personnel) est ok
>>>> Si tu arrives bien à éditer cette fiche, quand tu demandes la
>>>> publication et que tu te connectes avec ton compte "roualdes" c'est
>>>> là que tu n'as pas le dossier virtuel "Ressources que je dois
>>>> modérer" ?
>>>>
>>>> Merci
>>>> Yohan
>>>>
>>>> Yannis Roualdes a écrit :

>>>>> Bonjour Yohann et Vincent,
>>>>>
>>>>> Premièrement vous ne pouvez pas savoir à quel point ça me chagrine
>>>>> de vous solliciter à ce point.
>>>>> Veuillez trouver en pièce jointe le fichier
>>>>> commons-parameters.properties.
>>>>> Pour ce qui est des logs je me suis peut être trompé dans les
>>>>> paramètres, je vais fouiller un peu plus, j'arriverai peut être à
>>>>> avoir quelques informations supplémentaires.
>>>>>
>>>>> Pour expliquer un peu les paramètres du fichier il faut savoir que
>>>>> notre annuaire possède un uid et un uidInterne, en fait
>>>>> l'authentification utilise l'uidInterne.
>>>>>
>>>>> PS1 : désolé pour la réponse tardive
>>>>>
>>>>> Yohan Colmant a écrit :

>>>>>> Bonjour Yannis,
>>>>>>
>>>>>> Est-ce que tu peux envoyer ton fichier
>>>>>> commons-parameters.properties stp ? N'oublie pas de masquer les
>>>>>> mots de passe.
>>>>>>
>>>>>> Merci
>>>>>> Yohan
>>>>>>
>>>>>> Yannis Roualdes a écrit :

>>>>>>> Re-bonjour,
>>>>>>>
>>>>>>> J'ai pu avoir accès aux logs des communications entre ORI-OAI et
>>>>>>> l'annuaire LDAP de mon établissement, ceci uniquement pour le
>>>>>>> login puisque c'est ce qui pose problème. Le seul souci que j'ai
>>>>>>> pu noter est qu'un filtre portant sur la recherche de groupe ne
>>>>>>> renvoie rien. Par contre les filtres des groupes additionnels
>>>>>>> fonctionnent correctement. Est ce le problème ? Sachant que je
>>>>>>> n'utilise pas de groupes spécifiques à ORI-OAI, uniquement les
>>>>>>> groupes additionnels.
>>>>>>> Par ailleurs j'ai modifié le log4j.properties du workflow pour
>>>>>>> avoir les logs acegi, mais même en mettant INFO je n'ai pas le
>>>>>>> détails des requêtes et réponses, y a t il des paramètres
>>>>>>> particuliers ?
>>>>>>>
>>>>>>> Cordialement.
>>>>>>>
>>>>>>> Henri Jacob a écrit :

>>>>>>>> Re-bonjour Yannis,
>>>>>>>>
>>>>>>>> As-tu la possibilité de tester tes filtres avec un browser ldap ?
>>>>>>>>
>>>>>>>> Henri
>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>> Re-bonjour tout le monde,
>>>>>>>>>
>>>>>>>>> Me re-voila avec toujours le même problème. J'ai mis les
>>>>>>>>> filtres les moins contraignant au niveau des groupes
>>>>>>>>> additionnels (uid=*) pour
>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL, et des filtres du style
>>>>>>>>> (objectClass=*) pour WORKFLOW_LDAP_PEOPLE_FILTER. Alors que
>>>>>>>>> l'authentification CAS se passe très bien je n'arrive toujours
>>>>>>>>> pas à appartenir à un groupe.
>>>>>>>>> Est ce que d'autres personnes ont été confrontées au même
>>>>>>>>> problème, si oui comme a t il été résolu ?
>>>>>>>>>
>>>>>>>>> Bien à vous.
>>>>>>>>>
>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>> Je ne vois rien d'incorrect.
>>>>>>>>>> Le problème vient surement d'une mauvaise définition des
>>>>>>>>>> groupes additionnels .
>>>>>>>>>> Il faut vérifier la valeur des paramètres :
>>>>>>>>>> ldap.virtualgroup.filter.all,
>>>>>>>>>> ldap.virtualgroup.filter.moderators,
>>>>>>>>>> ldap.virtualgroup.filter.admins
>>>>>>>>>> Le mapping ldap est sans doute erroné.
>>>>>>>>>>
>>>>>>>>>> Désolé de ne pas pouvoir faire plus.
>>>>>>>>>> Henri
>>>>>>>>>>
>>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>>> Bonjour,
>>>>>>>>>>>
>>>>>>>>>>> Excusez moi pour cette réponse tardive, en pièce jointe vous
>>>>>>>>>>> trouverez l'archive de ces fichiers. Il est possible que le
>>>>>>>>>>> problème vienne des intitulés des propriétés utilisé dans
>>>>>>>>>>> notre annuaire, je teste en ce moment même.
>>>>>>>>>>> Cordialement.
>>>>>>>>>>>
>>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>>> Bonjour,
>>>>>>>>>>>>
>>>>>>>>>>>> est-il possible de voir la config locale, au moins les
>>>>>>>>>>>> fichiers :
>>>>>>>>>>>> commons-parameters.properties
>>>>>>>>>>>> conf/properties/spring/spring-categories.xml
>>>>>>>>>>>> conf/properties/spring/spring-metadata-types.xml
>>>>>>>>>>>> conf/propertiesspring/acegi/acegi-*.xml
>>>>>>>>>>>>
>>>>>>>>>>>> Henri
>>>>>>>>>>>>
>>>>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>>>>> Bonjour,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Merci pour cette réponse, elle confirme qu'il n'est pas
>>>>>>>>>>>>> nécessaire de créer des groupes LDAP spécifiques à
>>>>>>>>>>>>> ORI-OAI, cela m'arrange.
>>>>>>>>>>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs
>>>>>>>>>>>>> tests et quelque soit le filtre
>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand je me connecte
>>>>>>>>>>>>> je ne fais partie d'aucun groupe. J'ai bien spécifié
>>>>>>>>>>>>> l'intitulé exact de l'objectClass pour le personnel de
>>>>>>>>>>>>> notre établissement. En fait je ne vois pas où j'ai pu me
>>>>>>>>>>>>> tromper c'est pourquoi je bloque.
>>>>>>>>>>>>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL
>>>>>>>>>>>>> soit égal à (objectClass=Person) ou à (uid=moniud) ça ne
>>>>>>>>>>>>> marche pas.
>>>>>>>>>>>>> Bonne journée.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>>>>> Bonjour Yannis,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Je réponds dans le message
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yannis Roualdes wrote:

>>>>>>>>>>>>>>> Bonjour à tous,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cette question vous paraîtra peut être stupide mais
>>>>>>>>>>>>>>> je découvre LDAP (et ses filtres).
>>>>>>>>>>>>>>> Premièrement il me semble, mais détrompez moi s'il le
>>>>>>>>>>>>>>> faut, qu'il n'est pas nécessaire d'avoir des groupes
>>>>>>>>>>>>>>> LDAP scpécifiques pour utiliser le workflow, si j'ai
>>>>>>>>>>>>>>> bien compris on peut tout à fait gérer ces groupes avec
>>>>>>>>>>>>>>> les paramètres LDAP du workflow.

>>>>>>>>>>>>>> Dans le workflow, le terme acegi "recipient" représente
>>>>>>>>>>>>>> soit un utilisateur, soit un groupe d'utilisateurs , soit
>>>>>>>>>>>>>> un role. On peut donc en effet se passer de la notion de
>>>>>>>>>>>>>> groupe d'utilisateurs. On peut par exemple attribuer le
>>>>>>>>>>>>>> role "MODERATOR" directement à plusieurs utilisateurs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Les "recipient" groupes ne sont qu'une facilité de
>>>>>>>>>>>>>> définition et d'administration des utilisateurs et de
>>>>>>>>>>>>>> leurs roles .
>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> C'est là mon problème : je suis bien reconnu lors de
>>>>>>>>>>>>>>> l'authentification CAS, mais lorsque j'affiche le profil
>>>>>>>>>>>>>>> dans l'interface si l'uid est correct je n'ai aucune
>>>>>>>>>>>>>>> autre information, je n'appartiens à aucun groupe et je
>>>>>>>>>>>>>>> n'ai donc aucune autorisation. Le filtre que j'utilise
>>>>>>>>>>>>>>> dans commons-parameters.properties pour
>>>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid).
>>>>>>>>>>>>>>> Pour les autres paramètres c'est similaire.

>>>>>>>>>>>>>> Le seul groupe par défaut est "all" . L'utilisateur
>>>>>>>>>>>>>> doit en faire partie , sinon il ne pourra rien faire .
>>>>>>>>>>>>>> Par défaut, toutes les entrées ldap de classes Person (ie
>>>>>>>>>>>>>> tous les utilisateurs) en font partie :
>>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> J'ignore totalement pourquoi ça ne fonctionnement pas,
>>>>>>>>>>>>>>> me faut il modifier des fichies ACEGI ?

>>>>>>>>>>>>>> En général, dès que l'on modifie les droits: persmissions
>>>>>>>>>>>>>> ou roles (en gros, dès que l'on touche à
>>>>>>>>>>>>>> acegi-acls-root.xml, il faut faire :
>>>>>>>>>>>>>> ant update-acls

>>>>>>>>>>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de
>>>>>>>>>>>>>>> réponse, ou alors j'ai du passer à côté, si c'est le cas
>>>>>>>>>>>>>>> veuillez m'excuser.
>>>>>>>>>>>>>>> Merci pour votre aide.
>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Je ne suis pas sûr de répondre complètement à la
>>>>>>>>>>>>>> question, car je ne connais pas ta configuration.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Henri

>>>>>>>>>>>>>
>>>>>>>>>>>>>

>>>>>>>>>>>>

>>>>>>>>>>>
>>>>>>>>>>>

>>>>>>>>>>

>>>>>>>>>
>>>>>>>>>

>>>>>>>>

>>>>>>>
>>>>>>>

>>>>>>
>>>>>> --
>>>>>> Ce message a été vérifié par
>>>>>> pour des virus ou des polluriels et rien de
>>>>>> suspect n'a été trouvé.

>>>>>
>>>>>

>>>>
>>>> --
>>>> Ce message a été vérifié par
>>>> pour des virus ou des polluriels et rien de
>>>> suspect n'a été trouvé.

>>>
>>>

>>
>> --
>> Ce message a été vérifié par
>> pour des virus ou des polluriels et rien de
>> suspect n'a été trouvé.

>
>

> dans l'interface auteur, est-ce que tu arrives à faire "demander à
> publier" ?
> en tant que modérateur, est-ce que tu peux publier ?
>
> Yohan
>
> Yannis Roualdes a écrit :

>> Je viens de faire plusieurs tests en restreignant les filtres "all"
>> et "moderateur" à mon id.
>> Je parviens à créer, sauvegarder et éditer une fiche, par contre
>> impossible de faire autre chose.
>> L'affichage du profil ne mentionne aucun groupe, rôle ni permission.
>>
>>
>> Yannis Roualdes a écrit :

>>> Hélas j'avais déjà essayé, en fait j'ai testé beaucoup de
>>> combinaisons de filtres et je ne parviens pas à faire partie d'un
>>> groupe.
>>>
>>> Yohan Colmant a écrit :

>>>> Merci Yannis pour ces points.
>>>> Si tu mets ceci:
>>>>
>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(uid=roualdes)
>>>>
>>>> ça devrait te permettre d'initier un workflow. Tu as déjà essayé ?
>>>> Si ça marche, le problème peut effectivement venir de la limite de
>>>> (objectClass=personnel)
>>>>
>>>> Yohan
>>>>
>>>>
>>>>
>>>> Yannis Roualdes a écrit :

>>>>> Bonjour Yohann,
>>>>>
>>>>> "uidInterne=roualdes,ou=People,dc=upmc,dc=fr" est bien une branche
>>>>> pour autant que je puisse en juger (ldapsearch me renvoie les
>>>>> bonnes données).
>>>>>
>>>>> "(objectClass=personnel)" sans autre restriction renvoie des
>>>>> données mais de manière incomplète : la taille limite est atteinte
>>>>> assez rapidement, donc il n'y pas les données de l'ensemble des
>>>>> personnes concernées par ce filtre.
>>>>>
>>>>> Il n'y a aucune différence lorsque je modifie
>>>>> WORKFLOW_LDAP_PEOPLE_UID_ATTRIBUTE et
>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_MODERATORS.
>>>>>
>>>>> Pour le moment lorsque je me connecte je peux créer une nouvelle
>>>>> fiche mais pas la sauvegarder (je n'ai pas les droits d'initier un
>>>>> workflow). Le souci vient peut être du fait que
>>>>> (objectClass=personnel) ne renvoie que des données partielles du à
>>>>> la limite de taille de la réponse.
>>>>>
>>>>> Voila tout ce que je peux dire pour le moment.
>>>>>
>>>>> En tout cas merci pour ton aide.
>>>>>
>>>>>
>>>>> Yohan Colmant a écrit :

>>>>>> Bonjour Yannis,
>>>>>>
>>>>>> Peux-tu vérifier certaines choses par rapport à ton LDAP stp ?
>>>>>>
>>>>>> - "uidInterne=roualdes,ou=People,dc=upmc,dc=fr" (avec majuscule)
>>>>>> est bien une branche de ton LDAP ?
>>>>>>
>>>>>> - "(objectClass=personnel)" renvoie bien des entrées ?
>>>>>>
>>>>>> - quelle différence ça fait si tu changes l'attribut suivant en :
>>>>>> "WORKFLOW_LDAP_PEOPLE_UID_ATTRIBUTE=uidInterne" ?
>>>>>>
>>>>>> - idem pour
>>>>>> "WORKFLOW_ACEGI_ADD_GROUPS_FILTER_MODERATORS=(uidInterne=roualdes)"
>>>>>>
>>>>>> Aussi, quand tu te connectes avec n'importe quel compte
>>>>>> personnel, est-ce que tu arrives à éditer une fiche pédagogique ?
>>>>>> Si oui, tu fais partie du groupe ALL, donc
>>>>>> (objectClass=personnel) est ok
>>>>>> Si tu arrives bien à éditer cette fiche, quand tu demandes la
>>>>>> publication et que tu te connectes avec ton compte "roualdes"
>>>>>> c'est là que tu n'as pas le dossier virtuel "Ressources que je
>>>>>> dois modérer" ?
>>>>>>
>>>>>> Merci
>>>>>> Yohan
>>>>>>
>>>>>> Yannis Roualdes a écrit :

>>>>>>> Bonjour Yohann et Vincent,
>>>>>>>
>>>>>>> Premièrement vous ne pouvez pas savoir à quel point ça me
>>>>>>> chagrine de vous solliciter à ce point.
>>>>>>> Veuillez trouver en pièce jointe le fichier
>>>>>>> commons-parameters.properties.
>>>>>>> Pour ce qui est des logs je me suis peut être trompé dans les
>>>>>>> paramètres, je vais fouiller un peu plus, j'arriverai peut être
>>>>>>> à avoir quelques informations supplémentaires.
>>>>>>>
>>>>>>> Pour expliquer un peu les paramètres du fichier il faut savoir
>>>>>>> que notre annuaire possède un uid et un uidInterne, en fait
>>>>>>> l'authentification utilise l'uidInterne.
>>>>>>>
>>>>>>> PS1 : désolé pour la réponse tardive
>>>>>>>
>>>>>>> Yohan Colmant a écrit :

>>>>>>>> Bonjour Yannis,
>>>>>>>>
>>>>>>>> Est-ce que tu peux envoyer ton fichier
>>>>>>>> commons-parameters.properties stp ? N'oublie pas de masquer les
>>>>>>>> mots de passe.
>>>>>>>>
>>>>>>>> Merci
>>>>>>>> Yohan
>>>>>>>>
>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>> Re-bonjour,
>>>>>>>>>
>>>>>>>>> J'ai pu avoir accès aux logs des communications entre ORI-OAI
>>>>>>>>> et l'annuaire LDAP de mon établissement, ceci uniquement pour
>>>>>>>>> le login puisque c'est ce qui pose problème. Le seul souci que
>>>>>>>>> j'ai pu noter est qu'un filtre portant sur la recherche de
>>>>>>>>> groupe ne renvoie rien. Par contre les filtres des groupes
>>>>>>>>> additionnels fonctionnent correctement. Est ce le problème ?
>>>>>>>>> Sachant que je n'utilise pas de groupes spécifiques à ORI-OAI,
>>>>>>>>> uniquement les groupes additionnels.
>>>>>>>>> Par ailleurs j'ai modifié le log4j.properties du workflow pour
>>>>>>>>> avoir les logs acegi, mais même en mettant INFO je n'ai pas le
>>>>>>>>> détails des requêtes et réponses, y a t il des paramètres
>>>>>>>>> particuliers ?
>>>>>>>>>
>>>>>>>>> Cordialement.
>>>>>>>>>
>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>> Re-bonjour Yannis,
>>>>>>>>>>
>>>>>>>>>> As-tu la possibilité de tester tes filtres avec un browser
>>>>>>>>>> ldap ?
>>>>>>>>>>
>>>>>>>>>> Henri
>>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>>> Re-bonjour tout le monde,
>>>>>>>>>>>
>>>>>>>>>>> Me re-voila avec toujours le même problème. J'ai mis les
>>>>>>>>>>> filtres les moins contraignant au niveau des groupes
>>>>>>>>>>> additionnels (uid=*) pour
>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL, et des filtres du
>>>>>>>>>>> style (objectClass=*) pour WORKFLOW_LDAP_PEOPLE_FILTER.
>>>>>>>>>>> Alors que l'authentification CAS se passe très bien je
>>>>>>>>>>> n'arrive toujours pas à appartenir à un groupe.
>>>>>>>>>>> Est ce que d'autres personnes ont été confrontées au même
>>>>>>>>>>> problème, si oui comme a t il été résolu ?
>>>>>>>>>>>
>>>>>>>>>>> Bien à vous.
>>>>>>>>>>>
>>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>>> Je ne vois rien d'incorrect.
>>>>>>>>>>>> Le problème vient surement d'une mauvaise définition des
>>>>>>>>>>>> groupes additionnels .
>>>>>>>>>>>> Il faut vérifier la valeur des paramètres :
>>>>>>>>>>>> ldap.virtualgroup.filter.all,
>>>>>>>>>>>> ldap.virtualgroup.filter.moderators,
>>>>>>>>>>>> ldap.virtualgroup.filter.admins
>>>>>>>>>>>> Le mapping ldap est sans doute erroné.
>>>>>>>>>>>>
>>>>>>>>>>>> Désolé de ne pas pouvoir faire plus.
>>>>>>>>>>>> Henri
>>>>>>>>>>>>
>>>>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>>>>> Bonjour,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Excusez moi pour cette réponse tardive, en pièce jointe
>>>>>>>>>>>>> vous trouverez l'archive de ces fichiers. Il est possible
>>>>>>>>>>>>> que le problème vienne des intitulés des propriétés
>>>>>>>>>>>>> utilisé dans notre annuaire, je teste en ce moment même.
>>>>>>>>>>>>> Cordialement.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>>>>> Bonjour,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> est-il possible de voir la config locale, au moins les
>>>>>>>>>>>>>> fichiers :
>>>>>>>>>>>>>> commons-parameters.properties
>>>>>>>>>>>>>> conf/properties/spring/spring-categories.xml
>>>>>>>>>>>>>> conf/properties/spring/spring-metadata-types.xml
>>>>>>>>>>>>>> conf/propertiesspring/acegi/acegi-*.xml
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Henri
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>>>>>>> Bonjour,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Merci pour cette réponse, elle confirme qu'il n'est
>>>>>>>>>>>>>>> pas nécessaire de créer des groupes LDAP spécifiques à
>>>>>>>>>>>>>>> ORI-OAI, cela m'arrange.
>>>>>>>>>>>>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs
>>>>>>>>>>>>>>> tests et quelque soit le filtre
>>>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand je me
>>>>>>>>>>>>>>> connecte je ne fais partie d'aucun groupe. J'ai bien
>>>>>>>>>>>>>>> spécifié l'intitulé exact de l'objectClass pour le
>>>>>>>>>>>>>>> personnel de notre établissement. En fait je ne vois pas
>>>>>>>>>>>>>>> où j'ai pu me tromper c'est pourquoi je bloque.
>>>>>>>>>>>>>>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL
>>>>>>>>>>>>>>> soit égal à (objectClass=Person) ou à (uid=moniud) ça ne
>>>>>>>>>>>>>>> marche pas.
>>>>>>>>>>>>>>> Bonne journée.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>>>>>>> Bonjour Yannis,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Je réponds dans le message
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yannis Roualdes wrote:

>>>>>>>>>>>>>>>>> Bonjour à tous,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cette question vous paraîtra peut être stupide mais
>>>>>>>>>>>>>>>>> je découvre LDAP (et ses filtres).
>>>>>>>>>>>>>>>>> Premièrement il me semble, mais détrompez moi s'il le
>>>>>>>>>>>>>>>>> faut, qu'il n'est pas nécessaire d'avoir des groupes
>>>>>>>>>>>>>>>>> LDAP scpécifiques pour utiliser le workflow, si j'ai
>>>>>>>>>>>>>>>>> bien compris on peut tout à fait gérer ces groupes
>>>>>>>>>>>>>>>>> avec les paramètres LDAP du workflow.

>>>>>>>>>>>>>>>> Dans le workflow, le terme acegi "recipient" représente
>>>>>>>>>>>>>>>> soit un utilisateur, soit un groupe d'utilisateurs ,
>>>>>>>>>>>>>>>> soit un role. On peut donc en effet se passer de la
>>>>>>>>>>>>>>>> notion de groupe d'utilisateurs. On peut par exemple
>>>>>>>>>>>>>>>> attribuer le role "MODERATOR" directement à plusieurs
>>>>>>>>>>>>>>>> utilisateurs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Les "recipient" groupes ne sont qu'une facilité de
>>>>>>>>>>>>>>>> définition et d'administration des utilisateurs et de
>>>>>>>>>>>>>>>> leurs roles .
>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>> C'est là mon problème : je suis bien reconnu lors
>>>>>>>>>>>>>>>>> de l'authentification CAS, mais lorsque j'affiche le
>>>>>>>>>>>>>>>>> profil dans l'interface si l'uid est correct je n'ai
>>>>>>>>>>>>>>>>> aucune autre information, je n'appartiens à aucun
>>>>>>>>>>>>>>>>> groupe et je n'ai donc aucune autorisation. Le filtre
>>>>>>>>>>>>>>>>> que j'utilise dans commons-parameters.properties pour
>>>>>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid).
>>>>>>>>>>>>>>>>> Pour les autres paramètres c'est similaire.

>>>>>>>>>>>>>>>> Le seul groupe par défaut est "all" . L'utilisateur
>>>>>>>>>>>>>>>> doit en faire partie , sinon il ne pourra rien faire .
>>>>>>>>>>>>>>>> Par défaut, toutes les entrées ldap de classes Person
>>>>>>>>>>>>>>>> (ie tous les utilisateurs) en font partie :
>>>>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>> J'ignore totalement pourquoi ça ne fonctionnement pas,
>>>>>>>>>>>>>>>>> me faut il modifier des fichies ACEGI ?

>>>>>>>>>>>>>>>> En général, dès que l'on modifie les droits:
>>>>>>>>>>>>>>>> persmissions ou roles (en gros, dès que l'on touche à
>>>>>>>>>>>>>>>> acegi-acls-root.xml, il faut faire :
>>>>>>>>>>>>>>>> ant update-acls

>>>>>>>>>>>>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de
>>>>>>>>>>>>>>>>> réponse, ou alors j'ai du passer à côté, si c'est le
>>>>>>>>>>>>>>>>> cas veuillez m'excuser.
>>>>>>>>>>>>>>>>> Merci pour votre aide.
>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Je ne suis pas sûr de répondre complètement à la
>>>>>>>>>>>>>>>> question, car je ne connais pas ta configuration.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Henri

>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>

>>>>>>>>>>>>>
>>>>>>>>>>>>>

>>>>>>>>>>>>

>>>>>>>>>>>
>>>>>>>>>>>

>>>>>>>>>>

>>>>>>>>>
>>>>>>>>>

>>>>>>>>
>>>>>>>> --
>>>>>>>> Ce message a été vérifié par
>>>>>>>> pour des virus ou des polluriels et rien de
>>>>>>>> suspect n'a été trouvé.

>>>>>>>
>>>>>>>

>>>>>>
>>>>>> --
>>>>>> Ce message a été vérifié par
>>>>>> pour des virus ou des polluriels et rien de
>>>>>> suspect n'a été trouvé.

>>>>>
>>>>>

>>>>
>>>> --
>>>> Ce message a été vérifié par
>>>> pour des virus ou des polluriels et rien de
>>>> suspect n'a été trouvé.

>>>
>>>

>>
>>

>
> --
> Ce message a été vérifié par
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.

> Si tu édites une fiches LOM, que tu l'enregistres.
> Quand tu vas dans "Mes ressources en cours d'édition", tu n'as pas le
> bouton "Demander à publier" dans la colonne "Demander l'étapesuivante" ?
>
> Yohan
>
> Yannis Roualdes a écrit :

>> Il m'est impossible de demander la publication ou de publier quelque
>> soit le rôle que j'essaye de me donner, l'interface propose les mêmes
>> actions (créer et éditer des ressources).
>>
>> Yohan Colmant a écrit :

>>> dans l'interface auteur, est-ce que tu arrives à faire "demander à
>>> publier" ?
>>> en tant que modérateur, est-ce que tu peux publier ?
>>>
>>> Yohan
>>>
>>> Yannis Roualdes a écrit :

>>>> Je viens de faire plusieurs tests en restreignant les filtres "all"
>>>> et "moderateur" à mon id.
>>>> Je parviens à créer, sauvegarder et éditer une fiche, par contre
>>>> impossible de faire autre chose.
>>>> L'affichage du profil ne mentionne aucun groupe, rôle ni permission.
>>>>
>>>>
>>>> Yannis Roualdes a écrit :

>>>>> Hélas j'avais déjà essayé, en fait j'ai testé beaucoup de
>>>>> combinaisons de filtres et je ne parviens pas à faire partie d'un
>>>>> groupe.
>>>>>
>>>>> Yohan Colmant a écrit :

>>>>>> Merci Yannis pour ces points.
>>>>>> Si tu mets ceci:
>>>>>>
>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(uid=roualdes)
>>>>>>
>>>>>> ça devrait te permettre d'initier un workflow. Tu as déjà essayé
>>>>>> ? Si ça marche, le problème peut effectivement venir de la limite
>>>>>> de (objectClass=personnel)
>>>>>>
>>>>>> Yohan
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yannis Roualdes a écrit :

>>>>>>> Bonjour Yohann,
>>>>>>>
>>>>>>> "uidInterne=roualdes,ou=People,dc=upmc,dc=fr" est bien une
>>>>>>> branche pour autant que je puisse en juger (ldapsearch me
>>>>>>> renvoie les bonnes données).
>>>>>>>
>>>>>>> "(objectClass=personnel)" sans autre restriction renvoie des
>>>>>>> données mais de manière incomplète : la taille limite est
>>>>>>> atteinte assez rapidement, donc il n'y pas les données de
>>>>>>> l'ensemble des personnes concernées par ce filtre.
>>>>>>>
>>>>>>> Il n'y a aucune différence lorsque je modifie
>>>>>>> WORKFLOW_LDAP_PEOPLE_UID_ATTRIBUTE et
>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_MODERATORS.
>>>>>>>
>>>>>>> Pour le moment lorsque je me connecte je peux créer une nouvelle
>>>>>>> fiche mais pas la sauvegarder (je n'ai pas les droits d'initier
>>>>>>> un workflow). Le souci vient peut être du fait que
>>>>>>> (objectClass=personnel) ne renvoie que des données partielles du
>>>>>>> à la limite de taille de la réponse.
>>>>>>>
>>>>>>> Voila tout ce que je peux dire pour le moment.
>>>>>>>
>>>>>>> En tout cas merci pour ton aide.
>>>>>>>
>>>>>>>
>>>>>>> Yohan Colmant a écrit :

>>>>>>>> Bonjour Yannis,
>>>>>>>>
>>>>>>>> Peux-tu vérifier certaines choses par rapport à ton LDAP stp ?
>>>>>>>>
>>>>>>>> - "uidInterne=roualdes,ou=People,dc=upmc,dc=fr" (avec
>>>>>>>> majuscule) est bien une branche de ton LDAP ?
>>>>>>>>
>>>>>>>> - "(objectClass=personnel)" renvoie bien des entrées ?
>>>>>>>>
>>>>>>>> - quelle différence ça fait si tu changes l'attribut suivant en
>>>>>>>> : "WORKFLOW_LDAP_PEOPLE_UID_ATTRIBUTE=uidInterne" ?
>>>>>>>>
>>>>>>>> - idem pour
>>>>>>>> "WORKFLOW_ACEGI_ADD_GROUPS_FILTER_MODERATORS=(uidInterne=roualdes)"
>>>>>>>>
>>>>>>>>
>>>>>>>> Aussi, quand tu te connectes avec n'importe quel compte
>>>>>>>> personnel, est-ce que tu arrives à éditer une fiche pédagogique
>>>>>>>> ? Si oui, tu fais partie du groupe ALL, donc
>>>>>>>> (objectClass=personnel) est ok
>>>>>>>> Si tu arrives bien à éditer cette fiche, quand tu demandes la
>>>>>>>> publication et que tu te connectes avec ton compte "roualdes"
>>>>>>>> c'est là que tu n'as pas le dossier virtuel "Ressources que je
>>>>>>>> dois modérer" ?
>>>>>>>>
>>>>>>>> Merci
>>>>>>>> Yohan
>>>>>>>>
>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>> Bonjour Yohann et Vincent,
>>>>>>>>>
>>>>>>>>> Premièrement vous ne pouvez pas savoir à quel point ça me
>>>>>>>>> chagrine de vous solliciter à ce point.
>>>>>>>>> Veuillez trouver en pièce jointe le fichier
>>>>>>>>> commons-parameters.properties.
>>>>>>>>> Pour ce qui est des logs je me suis peut être trompé dans les
>>>>>>>>> paramètres, je vais fouiller un peu plus, j'arriverai peut
>>>>>>>>> être à avoir quelques informations supplémentaires.
>>>>>>>>>
>>>>>>>>> Pour expliquer un peu les paramètres du fichier il faut savoir
>>>>>>>>> que notre annuaire possède un uid et un uidInterne, en fait
>>>>>>>>> l'authentification utilise l'uidInterne.
>>>>>>>>>
>>>>>>>>> PS1 : désolé pour la réponse tardive
>>>>>>>>>
>>>>>>>>> Yohan Colmant a écrit :

>>>>>>>>>> Bonjour Yannis,
>>>>>>>>>>
>>>>>>>>>> Est-ce que tu peux envoyer ton fichier
>>>>>>>>>> commons-parameters.properties stp ? N'oublie pas de masquer
>>>>>>>>>> les mots de passe.
>>>>>>>>>>
>>>>>>>>>> Merci
>>>>>>>>>> Yohan
>>>>>>>>>>
>>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>>> Re-bonjour,
>>>>>>>>>>>
>>>>>>>>>>> J'ai pu avoir accès aux logs des communications entre
>>>>>>>>>>> ORI-OAI et l'annuaire LDAP de mon établissement, ceci
>>>>>>>>>>> uniquement pour le login puisque c'est ce qui pose problème.
>>>>>>>>>>> Le seul souci que j'ai pu noter est qu'un filtre portant sur
>>>>>>>>>>> la recherche de groupe ne renvoie rien. Par contre les
>>>>>>>>>>> filtres des groupes additionnels fonctionnent correctement.
>>>>>>>>>>> Est ce le problème ? Sachant que je n'utilise pas de groupes
>>>>>>>>>>> spécifiques à ORI-OAI, uniquement les groupes additionnels.
>>>>>>>>>>> Par ailleurs j'ai modifié le log4j.properties du workflow
>>>>>>>>>>> pour avoir les logs acegi, mais même en mettant INFO je n'ai
>>>>>>>>>>> pas le détails des requêtes et réponses, y a t il des
>>>>>>>>>>> paramètres particuliers ?
>>>>>>>>>>>
>>>>>>>>>>> Cordialement.
>>>>>>>>>>>
>>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>>> Re-bonjour Yannis,
>>>>>>>>>>>>
>>>>>>>>>>>> As-tu la possibilité de tester tes filtres avec un browser
>>>>>>>>>>>> ldap ?
>>>>>>>>>>>>
>>>>>>>>>>>> Henri
>>>>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>>>>> Re-bonjour tout le monde,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Me re-voila avec toujours le même problème. J'ai mis les
>>>>>>>>>>>>> filtres les moins contraignant au niveau des groupes
>>>>>>>>>>>>> additionnels (uid=*) pour
>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL, et des filtres du
>>>>>>>>>>>>> style (objectClass=*) pour WORKFLOW_LDAP_PEOPLE_FILTER.
>>>>>>>>>>>>> Alors que l'authentification CAS se passe très bien je
>>>>>>>>>>>>> n'arrive toujours pas à appartenir à un groupe.
>>>>>>>>>>>>> Est ce que d'autres personnes ont été confrontées au même
>>>>>>>>>>>>> problème, si oui comme a t il été résolu ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bien à vous.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>>>>> Je ne vois rien d'incorrect.
>>>>>>>>>>>>>> Le problème vient surement d'une mauvaise définition des
>>>>>>>>>>>>>> groupes additionnels .
>>>>>>>>>>>>>> Il faut vérifier la valeur des paramètres :
>>>>>>>>>>>>>> ldap.virtualgroup.filter.all,
>>>>>>>>>>>>>> ldap.virtualgroup.filter.moderators,
>>>>>>>>>>>>>> ldap.virtualgroup.filter.admins
>>>>>>>>>>>>>> Le mapping ldap est sans doute erroné.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Désolé de ne pas pouvoir faire plus.
>>>>>>>>>>>>>> Henri
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>>>>>>> Bonjour,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Excusez moi pour cette réponse tardive, en pièce jointe
>>>>>>>>>>>>>>> vous trouverez l'archive de ces fichiers. Il est
>>>>>>>>>>>>>>> possible que le problème vienne des intitulés des
>>>>>>>>>>>>>>> propriétés utilisé dans notre annuaire, je teste en ce
>>>>>>>>>>>>>>> moment même.
>>>>>>>>>>>>>>> Cordialement.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>>>>>>> Bonjour,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> est-il possible de voir la config locale, au moins les
>>>>>>>>>>>>>>>> fichiers :
>>>>>>>>>>>>>>>> commons-parameters.properties
>>>>>>>>>>>>>>>> conf/properties/spring/spring-categories.xml
>>>>>>>>>>>>>>>> conf/properties/spring/spring-metadata-types.xml
>>>>>>>>>>>>>>>> conf/propertiesspring/acegi/acegi-*.xml
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Henri
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>>>>>>>>> Bonjour,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Merci pour cette réponse, elle confirme qu'il n'est
>>>>>>>>>>>>>>>>> pas nécessaire de créer des groupes LDAP spécifiques à
>>>>>>>>>>>>>>>>> ORI-OAI, cela m'arrange.
>>>>>>>>>>>>>>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs
>>>>>>>>>>>>>>>>> tests et quelque soit le filtre
>>>>>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand je me
>>>>>>>>>>>>>>>>> connecte je ne fais partie d'aucun groupe. J'ai bien
>>>>>>>>>>>>>>>>> spécifié l'intitulé exact de l'objectClass pour le
>>>>>>>>>>>>>>>>> personnel de notre établissement. En fait je ne vois
>>>>>>>>>>>>>>>>> pas où j'ai pu me tromper c'est pourquoi je bloque.
>>>>>>>>>>>>>>>>> En résumé : que
>>>>>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL soit égal à
>>>>>>>>>>>>>>>>> (objectClass=Person) ou à (uid=moniud) ça ne marche pas.
>>>>>>>>>>>>>>>>> Bonne journée.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>>>>>>>>> Bonjour Yannis,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Je réponds dans le message
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yannis Roualdes wrote:

>>>>>>>>>>>>>>>>>>> Bonjour à tous,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Cette question vous paraîtra peut être stupide
>>>>>>>>>>>>>>>>>>> mais je découvre LDAP (et ses filtres).
>>>>>>>>>>>>>>>>>>> Premièrement il me semble, mais détrompez moi s'il
>>>>>>>>>>>>>>>>>>> le faut, qu'il n'est pas nécessaire d'avoir des
>>>>>>>>>>>>>>>>>>> groupes LDAP scpécifiques pour utiliser le workflow,
>>>>>>>>>>>>>>>>>>> si j'ai bien compris on peut tout à fait gérer ces
>>>>>>>>>>>>>>>>>>> groupes avec les paramètres LDAP du workflow.

>>>>>>>>>>>>>>>>>> Dans le workflow, le terme acegi "recipient"
>>>>>>>>>>>>>>>>>> représente soit un utilisateur, soit un groupe
>>>>>>>>>>>>>>>>>> d'utilisateurs , soit un role. On peut donc en effet
>>>>>>>>>>>>>>>>>> se passer de la notion de groupe d'utilisateurs. On
>>>>>>>>>>>>>>>>>> peut par exemple attribuer le role "MODERATOR"
>>>>>>>>>>>>>>>>>> directement à plusieurs utilisateurs.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Les "recipient" groupes ne sont qu'une facilité de
>>>>>>>>>>>>>>>>>> définition et d'administration des utilisateurs et de
>>>>>>>>>>>>>>>>>> leurs roles .
>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>> C'est là mon problème : je suis bien reconnu lors
>>>>>>>>>>>>>>>>>>> de l'authentification CAS, mais lorsque j'affiche le
>>>>>>>>>>>>>>>>>>> profil dans l'interface si l'uid est correct je n'ai
>>>>>>>>>>>>>>>>>>> aucune autre information, je n'appartiens à aucun
>>>>>>>>>>>>>>>>>>> groupe et je n'ai donc aucune autorisation. Le
>>>>>>>>>>>>>>>>>>> filtre que j'utilise dans
>>>>>>>>>>>>>>>>>>> commons-parameters.properties pour
>>>>>>>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est
>>>>>>>>>>>>>>>>>>> (uid=monUid). Pour les autres paramètres c'est
>>>>>>>>>>>>>>>>>>> similaire.

>>>>>>>>>>>>>>>>>> Le seul groupe par défaut est "all" .
>>>>>>>>>>>>>>>>>> L'utilisateur doit en faire partie , sinon il ne
>>>>>>>>>>>>>>>>>> pourra rien faire .
>>>>>>>>>>>>>>>>>> Par défaut, toutes les entrées ldap de classes Person
>>>>>>>>>>>>>>>>>> (ie tous les utilisateurs) en font partie :
>>>>>>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>> J'ignore totalement pourquoi ça ne fonctionnement
>>>>>>>>>>>>>>>>>>> pas, me faut il modifier des fichies ACEGI ?

>>>>>>>>>>>>>>>>>> En général, dès que l'on modifie les droits:
>>>>>>>>>>>>>>>>>> persmissions ou roles (en gros, dès que l'on touche à
>>>>>>>>>>>>>>>>>> acegi-acls-root.xml, il faut faire :
>>>>>>>>>>>>>>>>>> ant update-acls

>>>>>>>>>>>>>>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de
>>>>>>>>>>>>>>>>>>> réponse, ou alors j'ai du passer à côté, si c'est le
>>>>>>>>>>>>>>>>>>> cas veuillez m'excuser.
>>>>>>>>>>>>>>>>>>> Merci pour votre aide.
>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Je ne suis pas sûr de répondre complètement à la
>>>>>>>>>>>>>>>>>> question, car je ne connais pas ta configuration.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Henri

>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>

>>>>>>>>>>>>>
>>>>>>>>>>>>>

>>>>>>>>>>>>

>>>>>>>>>>>
>>>>>>>>>>>

>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ce message a été vérifié par
>>>>>>>>>> pour des virus ou des polluriels et rien de
>>>>>>>>>> suspect n'a été trouvé.

>>>>>>>>>
>>>>>>>>>

>>>>>>>>
>>>>>>>> --
>>>>>>>> Ce message a été vérifié par
>>>>>>>> pour des virus ou des polluriels et rien de
>>>>>>>> suspect n'a été trouvé.

>>>>>>>
>>>>>>>

>>>>>>
>>>>>> --
>>>>>> Ce message a été vérifié par
>>>>>> pour des virus ou des polluriels et rien de
>>>>>> suspect n'a été trouvé.

>>>>>
>>>>>

>>>>
>>>>

>>>
>>> --
>>> Ce message a été vérifié par
>>> pour des virus ou des polluriels et rien de
>>> suspect n'a été trouvé.

>>
>>

>
> --
> Ce message a été vérifié par
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.

> Bonjour Yannis,
> Je ne crois pas avoir testé le workflow avec un annuaire sur lequel
> l'uid d'une personne ne correspond pas au username.
> Il est possible qu'il y ait un problème dans le workflow autour de
> cela (?).
> Aussi pour simple test peux-tu configurer l'ensemble pour utiliser
> seulement uid (et non plus uidInterne) notamment en tant que username.
> Dis nous ce que cela donne, j'investirai alors de mon côté ce cas
> d'utilisation uid != username.
> Désolé pour les difficultés rencontrées.
> Vincent.
>
>
> Yannis Roualdes wrote:

>> Bonjour Yohann et Vincent,
>>
>> Premièrement vous ne pouvez pas savoir à quel point ça me chagrine de
>> vous solliciter à ce point.
>> Veuillez trouver en pièce jointe le fichier
>> commons-parameters.properties.
>> Pour ce qui est des logs je me suis peut être trompé dans les
>> paramètres, je vais fouiller un peu plus, j'arriverai peut être à
>> avoir quelques informations supplémentaires.
>>
>> Pour expliquer un peu les paramètres du fichier il faut savoir que
>> notre annuaire possède un uid et un uidInterne, en fait
>> l'authentification utilise l'uidInterne.
>>
>> PS1 : désolé pour la réponse tardive
>>
>> Yohan Colmant a écrit :

>>> Bonjour Yannis,
>>>
>>> Est-ce que tu peux envoyer ton fichier commons-parameters.properties
>>> stp ? N'oublie pas de masquer les mots de passe.
>>>
>>> Merci
>>> Yohan
>>>
>>> Yannis Roualdes a écrit :

>>>> Re-bonjour,
>>>>
>>>> J'ai pu avoir accès aux logs des communications entre ORI-OAI et
>>>> l'annuaire LDAP de mon établissement, ceci uniquement pour le login
>>>> puisque c'est ce qui pose problème. Le seul souci que j'ai pu noter
>>>> est qu'un filtre portant sur la recherche de groupe ne renvoie
>>>> rien. Par contre les filtres des groupes additionnels fonctionnent
>>>> correctement. Est ce le problème ? Sachant que je n'utilise pas de
>>>> groupes spécifiques à ORI-OAI, uniquement les groupes additionnels.
>>>> Par ailleurs j'ai modifié le log4j.properties du workflow pour
>>>> avoir les logs acegi, mais même en mettant INFO je n'ai pas le
>>>> détails des requêtes et réponses, y a t il des paramètres
>>>> particuliers ?
>>>>
>>>> Cordialement.
>>>>
>>>> Henri Jacob a écrit :

>>>>> Re-bonjour Yannis,
>>>>>
>>>>> As-tu la possibilité de tester tes filtres avec un browser ldap ?
>>>>>
>>>>> Henri
>>>>> Yannis Roualdes a écrit :

>>>>>> Re-bonjour tout le monde,
>>>>>>
>>>>>> Me re-voila avec toujours le même problème. J'ai mis les filtres
>>>>>> les moins contraignant au niveau des groupes additionnels (uid=*)
>>>>>> pour WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL, et des filtres du
>>>>>> style (objectClass=*) pour WORKFLOW_LDAP_PEOPLE_FILTER. Alors que
>>>>>> l'authentification CAS se passe très bien je n'arrive toujours
>>>>>> pas à appartenir à un groupe.
>>>>>> Est ce que d'autres personnes ont été confrontées au même
>>>>>> problème, si oui comme a t il été résolu ?
>>>>>>
>>>>>> Bien à vous.
>>>>>>
>>>>>> Henri Jacob a écrit :

>>>>>>> Je ne vois rien d'incorrect.
>>>>>>> Le problème vient surement d'une mauvaise définition des groupes
>>>>>>> additionnels .
>>>>>>> Il faut vérifier la valeur des paramètres :
>>>>>>> ldap.virtualgroup.filter.all,
>>>>>>> ldap.virtualgroup.filter.moderators,
>>>>>>> ldap.virtualgroup.filter.admins
>>>>>>> Le mapping ldap est sans doute erroné.
>>>>>>>
>>>>>>> Désolé de ne pas pouvoir faire plus.
>>>>>>> Henri
>>>>>>>
>>>>>>> Yannis Roualdes a écrit :

>>>>>>>> Bonjour,
>>>>>>>>
>>>>>>>> Excusez moi pour cette réponse tardive, en pièce jointe vous
>>>>>>>> trouverez l'archive de ces fichiers. Il est possible que le
>>>>>>>> problème vienne des intitulés des propriétés utilisé dans notre
>>>>>>>> annuaire, je teste en ce moment même.
>>>>>>>> Cordialement.
>>>>>>>>
>>>>>>>> Henri Jacob a écrit :

>>>>>>>>> Bonjour,
>>>>>>>>>
>>>>>>>>> est-il possible de voir la config locale, au moins les fichiers :
>>>>>>>>> commons-parameters.properties
>>>>>>>>> conf/properties/spring/spring-categories.xml
>>>>>>>>> conf/properties/spring/spring-metadata-types.xml
>>>>>>>>> conf/propertiesspring/acegi/acegi-*.xml
>>>>>>>>>
>>>>>>>>> Henri
>>>>>>>>>
>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>> Bonjour,
>>>>>>>>>>
>>>>>>>>>> Merci pour cette réponse, elle confirme qu'il n'est pas
>>>>>>>>>> nécessaire de créer des groupes LDAP spécifiques à ORI-OAI,
>>>>>>>>>> cela m'arrange.
>>>>>>>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs tests
>>>>>>>>>> et quelque soit le filtre
>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand je me connecte je
>>>>>>>>>> ne fais partie d'aucun groupe. J'ai bien spécifié l'intitulé
>>>>>>>>>> exact de l'objectClass pour le personnel de notre
>>>>>>>>>> établissement. En fait je ne vois pas où j'ai pu me tromper
>>>>>>>>>> c'est pourquoi je bloque.
>>>>>>>>>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL soit
>>>>>>>>>> égal à (objectClass=Person) ou à (uid=moniud) ça ne marche pas.
>>>>>>>>>> Bonne journée.
>>>>>>>>>>
>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>> Bonjour Yannis,
>>>>>>>>>>>
>>>>>>>>>>> Je réponds dans le message
>>>>>>>>>>>
>>>>>>>>>>> Yannis Roualdes wrote:

>>>>>>>>>>>> Bonjour à tous,
>>>>>>>>>>>>
>>>>>>>>>>>> Cette question vous paraîtra peut être stupide mais je
>>>>>>>>>>>> découvre LDAP (et ses filtres).
>>>>>>>>>>>> Premièrement il me semble, mais détrompez moi s'il le faut,
>>>>>>>>>>>> qu'il n'est pas nécessaire d'avoir des groupes LDAP
>>>>>>>>>>>> scpécifiques pour utiliser le workflow, si j'ai bien
>>>>>>>>>>>> compris on peut tout à fait gérer ces groupes avec les
>>>>>>>>>>>> paramètres LDAP du workflow.

>>>>>>>>>>> Dans le workflow, le terme acegi "recipient" représente soit
>>>>>>>>>>> un utilisateur, soit un groupe d'utilisateurs , soit un
>>>>>>>>>>> role. On peut donc en effet se passer de la notion de groupe
>>>>>>>>>>> d'utilisateurs. On peut par exemple attribuer le role
>>>>>>>>>>> "MODERATOR" directement à plusieurs utilisateurs.
>>>>>>>>>>>
>>>>>>>>>>> Les "recipient" groupes ne sont qu'une facilité de
>>>>>>>>>>> définition et d'administration des utilisateurs et de leurs
>>>>>>>>>>> roles .
>>>>>>>>>>>

>>>>>>>>>>>> C'est là mon problème : je suis bien reconnu lors de
>>>>>>>>>>>> l'authentification CAS, mais lorsque j'affiche le profil
>>>>>>>>>>>> dans l'interface si l'uid est correct je n'ai aucune autre
>>>>>>>>>>>> information, je n'appartiens à aucun groupe et je n'ai donc
>>>>>>>>>>>> aucune autorisation. Le filtre que j'utilise dans
>>>>>>>>>>>> commons-parameters.properties pour
>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid). Pour
>>>>>>>>>>>> les autres paramètres c'est similaire.

>>>>>>>>>>> Le seul groupe par défaut est "all" . L'utilisateur doit
>>>>>>>>>>> en faire partie , sinon il ne pourra rien faire .
>>>>>>>>>>> Par défaut, toutes les entrées ldap de classes Person (ie
>>>>>>>>>>> tous les utilisateurs) en font partie :
>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>>>>>>>

>>>>>>>>>>>> J'ignore totalement pourquoi ça ne fonctionnement pas, me
>>>>>>>>>>>> faut il modifier des fichies ACEGI ?

>>>>>>>>>>> En général, dès que l'on modifie les droits: persmissions ou
>>>>>>>>>>> roles (en gros, dès que l'on touche à acegi-acls-root.xml,
>>>>>>>>>>> il faut faire :
>>>>>>>>>>> ant update-acls

>>>>>>>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de réponse,
>>>>>>>>>>>> ou alors j'ai du passer à côté, si c'est le cas veuillez
>>>>>>>>>>>> m'excuser.
>>>>>>>>>>>> Merci pour votre aide.
>>>>>>>>>>>>

>>>>>>>>>>>
>>>>>>>>>>> Je ne suis pas sûr de répondre complètement à la question,
>>>>>>>>>>> car je ne connais pas ta configuration.
>>>>>>>>>>>
>>>>>>>>>>> Henri

>>>>>>>>>>
>>>>>>>>>>

>>>>>>>>>

>>>>>>>>
>>>>>>>>

>>>>>>>

>>>>>>
>>>>>>

>>>>>

>>>>
>>>>

>>>
>>> --
>>> Ce message a été vérifié par
>>> pour des virus ou des polluriels et rien de
>>> suspect n'a été trouvé.

>>
>>

> Bonjour Vincent,
>
> Le problème quand j'utilise exclusivement l'uid c'est que
> l'authentification CAS ne fonctionne plus puisqu'elle utilise
> l'uidInterne.
> Je suis obligé de le garder pour WORKFLOW_LDAP_USER_DN_PATTERN. Sinon
> je n'utilise que l'uid pour les filtres mais sans succès pour le moment.
> Je suis navré de ne pouvoir donner plus d'éléments.
>
> Vincent Bonamy a écrit :

>> Bonjour Yannis,
>> Je ne crois pas avoir testé le workflow avec un annuaire sur lequel
>> l'uid d'une personne ne correspond pas au username.
>> Il est possible qu'il y ait un problème dans le workflow autour de
>> cela (?).
>> Aussi pour simple test peux-tu configurer l'ensemble pour utiliser
>> seulement uid (et non plus uidInterne) notamment en tant que username.
>> Dis nous ce que cela donne, j'investirai alors de mon côté ce cas
>> d'utilisation uid != username.
>> Désolé pour les difficultés rencontrées.
>> Vincent.
>>
>>
>> Yannis Roualdes wrote:

>>> Bonjour Yohann et Vincent,
>>>
>>> Premièrement vous ne pouvez pas savoir à quel point ça me chagrine
>>> de vous solliciter à ce point.
>>> Veuillez trouver en pièce jointe le fichier
>>> commons-parameters.properties.
>>> Pour ce qui est des logs je me suis peut être trompé dans les
>>> paramètres, je vais fouiller un peu plus, j'arriverai peut être à
>>> avoir quelques informations supplémentaires.
>>>
>>> Pour expliquer un peu les paramètres du fichier il faut savoir que
>>> notre annuaire possède un uid et un uidInterne, en fait
>>> l'authentification utilise l'uidInterne.
>>>
>>> PS1 : désolé pour la réponse tardive
>>>
>>> Yohan Colmant a écrit :

>>>> Bonjour Yannis,
>>>>
>>>> Est-ce que tu peux envoyer ton fichier
>>>> commons-parameters.properties stp ? N'oublie pas de masquer les
>>>> mots de passe.
>>>>
>>>> Merci
>>>> Yohan
>>>>
>>>> Yannis Roualdes a écrit :

>>>>> Re-bonjour,
>>>>>
>>>>> J'ai pu avoir accès aux logs des communications entre ORI-OAI et
>>>>> l'annuaire LDAP de mon établissement, ceci uniquement pour le
>>>>> login puisque c'est ce qui pose problème. Le seul souci que j'ai
>>>>> pu noter est qu'un filtre portant sur la recherche de groupe ne
>>>>> renvoie rien. Par contre les filtres des groupes additionnels
>>>>> fonctionnent correctement. Est ce le problème ? Sachant que je
>>>>> n'utilise pas de groupes spécifiques à ORI-OAI, uniquement les
>>>>> groupes additionnels.
>>>>> Par ailleurs j'ai modifié le log4j.properties du workflow pour
>>>>> avoir les logs acegi, mais même en mettant INFO je n'ai pas le
>>>>> détails des requêtes et réponses, y a t il des paramètres
>>>>> particuliers ?
>>>>>
>>>>> Cordialement.
>>>>>
>>>>> Henri Jacob a écrit :

>>>>>> Re-bonjour Yannis,
>>>>>>
>>>>>> As-tu la possibilité de tester tes filtres avec un browser ldap ?
>>>>>>
>>>>>> Henri
>>>>>> Yannis Roualdes a écrit :

>>>>>>> Re-bonjour tout le monde,
>>>>>>>
>>>>>>> Me re-voila avec toujours le même problème. J'ai mis les filtres
>>>>>>> les moins contraignant au niveau des groupes additionnels
>>>>>>> (uid=*) pour WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL, et des
>>>>>>> filtres du style (objectClass=*) pour
>>>>>>> WORKFLOW_LDAP_PEOPLE_FILTER. Alors que l'authentification CAS se
>>>>>>> passe très bien je n'arrive toujours pas à appartenir à un groupe.
>>>>>>> Est ce que d'autres personnes ont été confrontées au même
>>>>>>> problème, si oui comme a t il été résolu ?
>>>>>>>
>>>>>>> Bien à vous.
>>>>>>>
>>>>>>> Henri Jacob a écrit :

>>>>>>>> Je ne vois rien d'incorrect.
>>>>>>>> Le problème vient surement d'une mauvaise définition des
>>>>>>>> groupes additionnels .
>>>>>>>> Il faut vérifier la valeur des paramètres :
>>>>>>>> ldap.virtualgroup.filter.all,
>>>>>>>> ldap.virtualgroup.filter.moderators,
>>>>>>>> ldap.virtualgroup.filter.admins
>>>>>>>> Le mapping ldap est sans doute erroné.
>>>>>>>>
>>>>>>>> Désolé de ne pas pouvoir faire plus.
>>>>>>>> Henri
>>>>>>>>
>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>> Bonjour,
>>>>>>>>>
>>>>>>>>> Excusez moi pour cette réponse tardive, en pièce jointe vous
>>>>>>>>> trouverez l'archive de ces fichiers. Il est possible que le
>>>>>>>>> problème vienne des intitulés des propriétés utilisé dans
>>>>>>>>> notre annuaire, je teste en ce moment même.
>>>>>>>>> Cordialement.
>>>>>>>>>
>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>> Bonjour,
>>>>>>>>>>
>>>>>>>>>> est-il possible de voir la config locale, au moins les
>>>>>>>>>> fichiers :
>>>>>>>>>> commons-parameters.properties
>>>>>>>>>> conf/properties/spring/spring-categories.xml
>>>>>>>>>> conf/properties/spring/spring-metadata-types.xml
>>>>>>>>>> conf/propertiesspring/acegi/acegi-*.xml
>>>>>>>>>>
>>>>>>>>>> Henri
>>>>>>>>>>
>>>>>>>>>> Yannis Roualdes a écrit :

>>>>>>>>>>> Bonjour,
>>>>>>>>>>>
>>>>>>>>>>> Merci pour cette réponse, elle confirme qu'il n'est pas
>>>>>>>>>>> nécessaire de créer des groupes LDAP spécifiques à ORI-OAI,
>>>>>>>>>>> cela m'arrange.
>>>>>>>>>>> Pour ce qui est du groupe "all" j'ai fait plusieurs tests
>>>>>>>>>>> et quelque soit le filtre
>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL quand je me connecte je
>>>>>>>>>>> ne fais partie d'aucun groupe. J'ai bien spécifié l'intitulé
>>>>>>>>>>> exact de l'objectClass pour le personnel de notre
>>>>>>>>>>> établissement. En fait je ne vois pas où j'ai pu me tromper
>>>>>>>>>>> c'est pourquoi je bloque.
>>>>>>>>>>> En résumé : que WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL soit
>>>>>>>>>>> égal à (objectClass=Person) ou à (uid=moniud) ça ne marche pas.
>>>>>>>>>>> Bonne journée.
>>>>>>>>>>>
>>>>>>>>>>> Henri Jacob a écrit :

>>>>>>>>>>>> Bonjour Yannis,
>>>>>>>>>>>>
>>>>>>>>>>>> Je réponds dans le message
>>>>>>>>>>>>
>>>>>>>>>>>> Yannis Roualdes wrote:

>>>>>>>>>>>>> Bonjour à tous,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cette question vous paraîtra peut être stupide mais je
>>>>>>>>>>>>> découvre LDAP (et ses filtres).
>>>>>>>>>>>>> Premièrement il me semble, mais détrompez moi s'il le
>>>>>>>>>>>>> faut, qu'il n'est pas nécessaire d'avoir des groupes LDAP
>>>>>>>>>>>>> scpécifiques pour utiliser le workflow, si j'ai bien
>>>>>>>>>>>>> compris on peut tout à fait gérer ces groupes avec les
>>>>>>>>>>>>> paramètres LDAP du workflow.

>>>>>>>>>>>> Dans le workflow, le terme acegi "recipient" représente
>>>>>>>>>>>> soit un utilisateur, soit un groupe d'utilisateurs , soit
>>>>>>>>>>>> un role. On peut donc en effet se passer de la notion de
>>>>>>>>>>>> groupe d'utilisateurs. On peut par exemple attribuer le
>>>>>>>>>>>> role "MODERATOR" directement à plusieurs utilisateurs.
>>>>>>>>>>>>
>>>>>>>>>>>> Les "recipient" groupes ne sont qu'une facilité de
>>>>>>>>>>>> définition et d'administration des utilisateurs et de leurs
>>>>>>>>>>>> roles .
>>>>>>>>>>>>

>>>>>>>>>>>>> C'est là mon problème : je suis bien reconnu lors de
>>>>>>>>>>>>> l'authentification CAS, mais lorsque j'affiche le profil
>>>>>>>>>>>>> dans l'interface si l'uid est correct je n'ai aucune autre
>>>>>>>>>>>>> information, je n'appartiens à aucun groupe et je n'ai
>>>>>>>>>>>>> donc aucune autorisation. Le filtre que j'utilise dans
>>>>>>>>>>>>> commons-parameters.properties pour
>>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL est (uid=monUid).
>>>>>>>>>>>>> Pour les autres paramètres c'est similaire.

>>>>>>>>>>>> Le seul groupe par défaut est "all" . L'utilisateur doit
>>>>>>>>>>>> en faire partie , sinon il ne pourra rien faire .
>>>>>>>>>>>> Par défaut, toutes les entrées ldap de classes Person (ie
>>>>>>>>>>>> tous les utilisateurs) en font partie :
>>>>>>>>>>>> WORKFLOW_ACEGI_ADD_GROUPS_FILTER_ALL=(objectClass=Person)
>>>>>>>>>>>>

>>>>>>>>>>>>> J'ignore totalement pourquoi ça ne fonctionnement pas, me
>>>>>>>>>>>>> faut il modifier des fichies ACEGI ?

>>>>>>>>>>>> En général, dès que l'on modifie les droits: persmissions
>>>>>>>>>>>> ou roles (en gros, dès que l'on touche à
>>>>>>>>>>>> acegi-acls-root.xml, il faut faire :
>>>>>>>>>>>> ant update-acls

>>>>>>>>>>>>> J'ai fait une recherche mais je n'ai pas trouvé de
>>>>>>>>>>>>> réponse, ou alors j'ai du passer à côté, si c'est le cas
>>>>>>>>>>>>> veuillez m'excuser.
>>>>>>>>>>>>> Merci pour votre aide.
>>>>>>>>>>>>>

>>>>>>>>>>>>
>>>>>>>>>>>> Je ne suis pas sûr de répondre complètement à la question,
>>>>>>>>>>>> car je ne connais pas ta configuration.
>>>>>>>>>>>>
>>>>>>>>>>>> Henri

>>>>>>>>>>>
>>>>>>>>>>>

>>>>>>>>>>

>>>>>>>>>
>>>>>>>>>

>>>>>>>>

>>>>>>>
>>>>>>>

>>>>>>

>>>>>
>>>>>

>>>>
>>>> --
>>>> Ce message a été vérifié par
>>>> pour des virus ou des polluriels et rien de
>>>> suspect n'a été trouvé.

>>>
>>>

>
>