Accès restreint V2 - Les objectifs

Attention, cette contribution est EN CHANTIER : elle n’est peut-être pas fonctionnelle.

A partir de l’expérience accumulée sur « Accès restreint » et « Accès restreint par groupe », le constat de la nécessité d’une fusion des deux plugins..

Les évolutions à venir

A titre d’explications sur les travaux à venir sur ce sujet, ci-dessous la reprise d’un post de Cedric sur spip-zone.

De : Cedric
Date : 26 mai 2007 15:38:34
Cc : spip-zone@
Les deux démarches sont incomplètes. Il faut donc les mettre en commun pour avoir :
-  les zones d’accès, que l’on définit bien unitairement comme actuellement (par rubrique, mais pourquoi pas par article dans le futur)
-  les profils, qui sont un ensemble d’autorisations d’accès à des zones, mais pourquoi pas aussi d’autres autorisations, comme pouvoir modifier un article publié précis ou autre)

C’est bien avec ces deux concepts que l’on aura toute la souplesse et la clarté recherchées.

Cedric

Travaux préparatoires coté documentation

Pour préparer la suite de l’évolution du code les deux plugins on été regroupés dans une rubrique-dossier commune. L’idée est de préparer un support pour pouvoir commencer à rassembler tout ce qui peut se dire sur le sujet, histoire de faciliter la réalisation de la future documentation.

N’hésitez pas à utiliser le présent forum par exemple pour les questions et notes, ou à proposer de nouveaux articles.

Rappel des objectifs du chantier (mise à jour 3 juin 2007)

Il est (re)précisé que l’objectif de ce chantier est bel est bien de faire ce qui est défini dans le mail de Cedric ci-dessus, ni plus ni moins (sauf si les auteurs en décident autrement bien sûr).

Les réflexions plus générales sur la gestion des droits et les processus de validation de SPIP sont certainement utiles, mais elles dépassent le cadre du présent chantier. L’expérience est que ce n’est pas en chargeant d’avance trop la barque de leurs objectifs que les plugins avancent, mais bien au contraire par avancées successives dans un cadre souple, au gré des besoins et de l’imagination de leurs auteurs. N’oublions pas que le présent débat n’est possible que parce que les deux précédents plugins, avec leurs limites maintenant analysées, on été créés d’abord .... voir aussi ce post à ce propos http://www.spip-contrib.net/Acces-r...
Un petit état des lieux est mis en débat sur ce post (6 février 2008)

Mise a jour du 13 janvier 2009

La version 3.0 du plugin Acces Restreint pour SPIP 2.0 est disponible ici Acces Restreint 3.0.
Ce plugin n’intègre pas les fonctionnalités d’accès restreint par groupe, mais est une évolution du plugin Accès Restreint, du point de vue ergonomique et performances.

Discussion

18 discussions

  • Bonjour,
    Personne n’a un truc concret pour la protection des documents joints ?
    Un htaccess ? pour une double authentification ?
    Merci de votre aide

    Répondre à ce message

  • 1

    Le plugin semble ne pas fonctionner avec spip V2. Est-ce qu’il est prévu de faire une mise à jour du plugin ? Si oui quand (au moins un ordre de grandeur... 1 semaine ? 1 mois ? 6 mois ? 1 an ?).
    Merci d’avance

    Répondre à ce message

  • 4

    Malgré toute la bonne volonté qui sera portée à la mise en place de ce plugin, il y a une chose spécifique à SPIP qu’il ne pourra pas modifier.

    Chaque document téléchargé sur un site SPIP est stocké dans un répertoire donné (/IMG/...) en fonction de son extension (par exemple .doc, .ppt, .xls...). L’authentification actuellement proposée ne restreint que l’accès aux rubriques, pas aux document joints.

    Par exemple, si je vous informe par un biais détourné qu’un document super confidentiel est ici http://www.monsitespip.com/spip/IMG/pdf/docsupersecret.pdf), vous pourrez y accéder sans avoir besoin de vous authentifier, puisque vous avez l’URL directe.

    Tant que cette façon d’accéder aux document n’est pas modifiée, toute volonté de faire de la sécurité me semblera limitée : SPIP pour des documents 100% publics, c’est très bien. Pour des rubriques privées, pourquoi pas. Pour des documents sûrs, non. Enfin, pas encore.

    N.B. : j’utilise SPIP depuis 3 ans, et je suis accro. C’est donc une simple remarque sur la façon de voir les choses.

    • Il y a une solution technique à ce besoin depuis un petit moment déjà, aussi bien dans Acces restreint 2.0 pour SPIP 1.9.2 que dans la version 3.0 pour SPIP 2.0 :
      Il est possible d’activer le filtrage par htaccess. Dans ce cas, toutes les urls de documents passent par un wrapper php qui vérifie les droits. En complement, il suffit de mettre un htaccess sur son répertoire IMG/ pour bloquer les acces directs.

      Mais attention, cette méthode a un cout serveur non négligeable car toutes les url d’images lancent un script php.

    • NOTA BENE :

      Je rajouterais en complément de la remarque de Daniel, sur la possibilité de passer outre les protections mises en place lorsque il s’agit d’un document intégré à une rubrique reservée, qu’il est également possible de récupérer ce même document via le fil d’info du squelette backend.html ou backend-breves.html lorsqu’il n’est pas desactivé.
      Prudence donc surtout si il s’agit de données quelques peu confidentielles.

      Pour palier rapidement au problème il est conseillé de mettre en place une redirection php dans le squelette dans un premier temps puis de supprimer la reference à la balise META dans l’entete de page.

      D’ailleur à voir les quelques sites utilisant l’un de ces modules il semble que les proprietaires aient déjà pris les devants.

      Bref on espère que la mécanique du futur plugin compatible SPIP 2 n’occassionnera plus ce type de frayeurs.

      Et bravo pour le boulot sur ces 2 plugins.

    • En réponse à Daniel pour son post du 15 décembre 20:36 :

      VOIR : http://www.spip-contrib.net/Acces-restreint-V2-les-objectifs#forum411135

      J’ai pu constater ce problème lors de la mise en place de l’intranet de mon établissement qui dans ce cas précis permet la consultation de notations par cycles d’élèves.

      Si l’on s’en tient à définir des noms de fichiers du type « notes_cycle1.pdf » puis « notes_cycle2.pdf » alors dans ce cas rien de plus facile pour les élèves d’un autre cycle de récupérer par déduction des fichiers de notes qui ne les concernent pas.
      Nous avons simplement intégré une chaine de 10 caractères dans le préfixe du fichier pour obtenir « duj4f5d2ss-notes_cycle1.pdf » puis « yhed584tg3-notes_cycle2.pdf »

      La il semble beaucoup difficile de tomber sur le bon fichier du premier coup.

    • Avez-vous une documentation pour la mise en place de ce filtrage.

      Nous travaillons pour un site gouvernemental et la sécurité d’accès aux fichiers joints aux articles est un critère de choix. Nous testons actuellement plusieurs CMS dont SPIP.

      Notre problématique : l’accès aux fichiers doit obéir aux mêmes règles que l’accès aux rubriques. Certains fichiers dans le répertoires ’IMG’ seront accessibles sans authentification (la majorité) mais d’autres nécessiteront une authentification.

      Merci.

    Répondre à ce message

  • 1

    Quelques mise au point à propos de cette V2 tant attendue...

    Non le projet de fusion n’est pas mort mais simplement en « stand-by prolongé » (le temps que je finisse de rénover chez moi histoire d’avoir un endroit pour poser mon ordi avant de recommencer à coder...).

    Non les 2 plugins ne sont pas développés indépendament puisque le système de restriction d’accès_groupes est tiré (pompé ?) des développements de Cedric pour le plugin acces_restreint.

    Par ailleurs le plugin acces_groupe semble présenter un problème en ce moment : lorsque le nombre de groupes/sous-groupes et de niveaux de rubriques/sous-rubriques est grand, le système de filtrage des accès n’ayant pas (du tout) été optimisé au niveau du nombre de requètes dans la base MySQL il génère un nombre totalement abusif d’accès à la base (jusqu’à + de 6000 pour afficher une seule page dixit un utilisateur sur spip-zone) ce qui le rend inutilisable dans ces conditions... La première étape de la fusion sera donc de modifier ce fonctionnement.
    Il faudra également « ajaxiser » les différents éléments de l’interface d’administration d’acces_groupes qui sont pour l’instant désespérément peu ergonomiques en terme de rapidité des opérations (la page est rechargée à chaque ajout d’utilisateur, sous-groupe ou rubrique « interdite »).

    Quand au principe de la fusion, après avoir pas mal réfléchi à la chose (le travail manuel ça laisse du temps pour penser à autre chose...) voici quelques pistes :

    • acces_restreint permet de faire des regroupements de rubriques « interdites » (= « zones ») et d’attribuer des droits d’accès a des utilisateurs mais seulement un par un (circonstance agravante, il faut aller sur la page de chaque auteur que l’on souhaite ajouter à une zone : rédhibitoire si on envisage son utilisation dans un spip avec 2000 utilisateurs)
    • acces_groupes permet de faire des regroupements d’utilisateurs (= « groupes ») et, pour chacun d’entre eux, de définir des rubriques « interdites » aux autres utilisateurs.
      Le point important est que (déja actuellement) dans acces_groupes chaque groupe est associé non pas à une rubrique « interdite » unique mais à un ensemble de rubriques : on retrouve donc là exactement la même possibilité de « zones interdites » que dans acces_restreint... (même si ça ne s’appelle pas une « zone », c’est le même concept)
    • dans les deux plugins les restrictions d’accès associées à une rubrique/groupe de rubriques peuvent concerner l’espace public ou l’espace privé ou les 2.
    • découle des points précédent que l’on peut donc déja avoir exactement les possibilités d’acces_restreint en utilisant acces_groupes... si ce n’est que l’interface d’administration d’acces_groupes est nettement plus lourde et compliquée à utiliser et que la logique d’utilisation est nettement moins intuitive que celle d’acces_restreint
    • en conclusion de ces quelques points, le chantier de fusion (hors des nécessaires optimisations d’acces_groupes citées plus haut) semble donc être d’arriver à un plugin qui propose la possibilité d’attribuer les zones interdites lors de l’édition/création d’un auteur (comme acces_restreint) avec une interface d’administration (la page où sont définies les zones interdites) qui permette également de gérer les accès à ces zone par le système de groupes (cf l’interface d’administration d’acces_groupes).
      Pour faciliter l’utilisation de cette interface d’admin on peut envisager de l’organiser avec la définition des zones en tête de page (i.e. récupérer l’interface actuelle d’acces_restreint histoire de ne pas déstabiliser les utilisateurs actuels de ce plugin) suivie de la partie de gestion des groupes/sous-groupes (i.e. avec exactement les mêmes outils que l’interface d’admin actuelle d’acces_groupes mais organisés différemment dans la page).
    • en ce qui concerne les (nombreuses) fonctionnalités supplémentaires demandées dans ce forum, j’avoue que pour l’instant la seule réponse que j’aurais à faire est : « le SVN est accessible à tous, on testera volontier vos développements lorsque vous aurez fini de les coder ! »

    Sur ce, je retourne à ma ponceuse et ma scie circulaire alors soyez patients...

    • Bonjour,

      Je sais que vous demandez d’être patient, mais ce plugin à venir semble être tellement pratique qu’il est bien difficile d’attendre.

      Est-il possible d’avoir une date approximative de sortie ? Juste pour savoir s’il suffise que j’attende encore un peu ou s’il faut que je me rabatte sur un des 2 anciens plugins (accès restreint V1 ou accès restreint par groupe) en attendant.

      Encore merci pour le boulot réalisé.

    Répondre à ce message

  • 1
    Pierre-Louis

    Bonjour.

    J’utilise actuellement le plugins accès restreint.

    J’ai deux types d’utilisateurs. Les premiers ont accès à une rubrique 1. Les second ont accès à la rubrique 1, mais aussi à la 1.1 .

    Mon problème est le suivant. Bien que je ne coche pas la case de la rubrique 1.1, lorsque je donne, aux premiers utilisateurs le droit de voir la rubrique 1, ils ont aussi accès à la 1.1.

    De ce fait, si j’attribue à des utilisateurs le droit de voir une rubrique, même si une rubrique englobée fait l’objet d’un accès restreint par ailleurs, ces utilisateurs y ont accès.

    Règlerez vous ce détail (IE : Pouvoir refuser l’accès à une sous rubrique même si on autorise l’accès à celle qui l’englobe) ? Ou peut-être n’utilise-je pas correctement le plugin ?

    J’utilise :

    — SPIP 1.9.2d

    — Accès restreint 2.0

    • cy_altern

      ce problème ne se pose pas si tu utilise le plugin accès_groupe : avec ce plugin les utilisateurs autorisés à voir ta rubrique 1 n’ont pas accès à la sous-rubrique 1.1.
      En revanche les utilisateurs autorisés à l’accès de la sous-rubrique 1.1 pourront y accéder MAIS ils ne verront pas la rubrique 1...ni la sous-rubrique 1.1 dans les menus => il faudra donc faire un lien qq part directement sur la sous-rubrique 1.1 si tu veux qu’ils aient un accès à celle-ci via la navigation dans le site.

    Répondre à ce message

  • Bonjour

    Juste une petite demande de précisions. Il est indiqué qu’on constate « la nécessité de fusion des deux plugins », accès par groupes et accès restreint. Pendant un temps, il semblait que le plugin accès par groupes soit un peu laissé à l’abandon, ce qui semblait logique au vu de la phrase ci-dessus.

    Mais actuellement, ce plugin a été mis à jour.

    Est-ce à dire que le projet de fusion est mort ?

    Les deux plugins sont-ils développés de façon indépendante ; le cas échéant, le choix s’avère cornélien pour l’utilisateur ...

    merci

    Répondre à ce message

  • 3

    A quand une version de test du plugin svp ?
    Y a t’il une roadmap ? (un planning pour parler plus français :-) ) ?

    • Même question...

    • Anthony F.

      Je ne serai pas plus original... ;)

      Cette v2 est très attendue, bon courage pour ce dev !

    • François Daniel Giezendanner

      En effet, la nouvelle version V2 est attendue avec grande impatience.

      Nous utilisons les plugins « Accès restreints par groupes » et « Accès restreints » mais récemment nous avons dû abandonner les plugin « Accès restreints par groupes » pour cause d’extrême ralentissement du site ainsi que nous l’avons mentionné ici :

      Pouvez-vous en tenir compte dans le développement de la version V2 ?

      Voici la teneur du message :

      Ce plugin est génial mais nous avons malheureusement constaté que dans certaines circonstances il se révèle trop lent !

      Dans un premier temps nous avions privilégié le plugin « Accès Restreints par groupes » par rapport au plugin « Accès Restreints ». Malheureusement, dans un site où nous avons défini de nombreux rédacteurs, administrateurs et visiteurs (130 utilisateurs) ainsi que de nombreux espaces restreints (14 espaces), le site est devenu extrêmement lent, au point de devenir inutilisable. Après moult essais, nous avons identifié que le plugin « Accès Restreints par groupes » était la cause de cette lenteur.

      Nous avons alors été obligé de l’abandonner et d’adopter le plugin « Accès Restreints » avec lequel nous n’observons pas de ralentissement du site.

      C’est fort dommage car ce plugin nous plaisait beaucoup !

      Meilleurs messages

      FDG

    Répondre à ce message

  • 7
    Committo, Ergo Sum

    Il me semble qu’une autre dimension n’est pas prise en compte par les deux plugins : l’accès restreint aux pièces jointes. A priori on ne devrait pas pouvoir accéder aux pièces jointes d’une article non publié. Ca se règle par .htacces dans IMG et une redéfinition de generer_url_document, mais on peut aller plus loin. Par exemple restreindre l’accès à certains types de documents mais pas d’autres.

    • Zab de Paris

      Oui, bonne idée cette fusion, et moi aussi, j’aimerais pouvoir télécharger les documents joints aux articles en zones « membres » dans un dossier protégé, mais télécharger des documents dans un autre dossier quand ils sont publics.
      Autrement dit, un téléchargement automatique dans le bon dossier selon l’appartenance de l’article à une zone protégée ou non.

      Et aussi, une protection du dossier qui ne demande pas à l’utilisateur enregistré de saisir à nouveau ses identifiants.

      Est-ce possible ?
      Merci !!!
      Zab

    • Joseph Larmarange

      Pour le moment, il existe le plugin DW2 qui offre un début de restriction d’accès aux documents. Ce plugin est peu connu car non documenté sur Contrib et non développé sur la zone.

      Une des possibilités pourrait consister à ce que les #URL_DOCUMENT pointent sur un script chargé de vérifier les droits et le cas échéant à lire le document en question, tandis qu’un fichier .htaccess interdirait purement et simplement l’accès direct aux documents via leur URL et n’autoriserai la lecture des documents uniquement via le script de vérification des droits.

      Normalement c’est jouable.

    • Joseph Larmarange

      Oups excusez moi. DW2 n’est semble-t-il pas développé sur la zone mais il dispose néanmoins d’une page sur Contrib : http://www.spip-contrib.net/Compteu....

    • Une contrib qui peut -être utile : Protéger le répertoire IMG/

    • Le problème de cette contrib, c’est que soit tous les documents sont protégés, soit aucun ne l’est. En plus, il n’y a pas moyen de faire une protection plus « fine » (ne serait-ce que visiteur/rédacteur/administrateur), mais je pense que ça devrait pouvoir bien s’interfacer avec la future V2.

      Les problèmes de l’accès restreint par DW2 me semblent plus importants. D’une part, il est bogué (il me suffit d’être logué en visiteur pour accéder à des documents pour administrateur, en fermant le formulaire de login) ; d’autre part les documents ne sont pas vraiment protégés. Il y a bien un script qui intercepte #URL_DOCUMENT, mais il fait une simple redirection vers le vrai fichier, qui reste accessible (si on interdit l’accès à IMG/ par un .htaccess, la redirection échoue) et téléchargeable librement une fois qu’on a son adresse.

      Cela dit, prendre le meilleur des deux n’a pas l’air insurmontable pour quelqu’un qui s’y connaît.

    • Des fois il suffit de demander ! Et même si DW2 n’est pas sur la zone, je reste joignable et accessible. si si ! ;-)
      N’ayant pas eu de retour sur la restriction proposé par ce plugin, je ne me suis guère foulé ! Mais ça va changé, je m’y remet d’ici peu ! Et la proposition devrais être un peu moins « inconséquente » !

    • Je suis assez d’accord avec tout le monde il me semble que la gestion des documents joint d’un article devrait faire partie du plugin Acces Restreint.

      Ca me semble logique mais peut être pas si evident que ca à dev je suppose !

    Répondre à ce message

  • 2
    Joseph LARMARANGE

    Il me semble pertinent pour faciliter les discussions à venir de convenir du point de vocabulaire ci-dessous :
    -  zone : ensemble de rubriques.
    -  groupe : ensemble d’auteurs
    -  profil : ensemble de droits, d’autorisation

    Actuellement, Accès restreint définit des zones et donne à des auteurs l’accès à certaines zones. Accès restreint par groupe définit des groupes puis précise les rubriques accessibles à un groupe.

    Les deux cas, il y a trois tables : la table des déifinitions, une table de jointure avec les rubriques et une table de jointure avec les auteurs.

    La définition actuelle des zones est problématique. En effet, une zone est actuellement définie comme un ensemble de branches. Autrement dit, si l’on coche une rubrique, alors toutes les sous-rubriques sont considérées comme appartenant à la zone. Cela interdit pour le moment de réaliser des déifinitions subtiles de zones. Il faudrait pouvoir définir des points d’entrée dans une zone mais également des points de sorties. La définition des zones ne doit pas imposer une arborescence à un site, l’arborescence d’un site devant découler d’une structure logique d’un point de vue sémantique. Au plugin de s’adpater aux différentes arborescences. Pour quelques éléments de réflexions sur le problème de l’héritage des droits et la définition des zones à l’aide de schémas, je renvois au document disponible ici : http://joseph.larmarange.net/Elemen....

    Pour l’heure, il me semble que le concept de zone, en tant qu’ensemble de rubriques, n’est utilisé que par le plugin Accès restreint. La restion reste posée de savoir s’il y aurait un intérêt de ce concept pour d’autres plugins. De la même manière, quels seraient les autres usages de groupes d’auteurs ?

    Si l’on veut disposer à la fois de groupes et d’auteurs, cela induit une multiplication des éléments. Nous aurions alors d’un côté la déclaration de zones avec une table zones et une table de jointure zones_rubriques, une déclaration de groupes d’auteurs, avec une table groupes et une table de jointure groupes_auteurs, et enfin il faudrait réaliser une table de jointure entre les zones et les groupes.

    Sur Spip-Zone, je proposais d’abandonner la notion de zone, ainsi que celle de groupe pour ne retenir que la notion de profils, profils étant entendu comme ensemble de droits. Fondamentalement, cela change techniquement peu de choses au plugin accès restreint tel qu’il existe actuellement. C’est la philosophie sous-jacente qui est modifiée. Dans le cadre de profils, on considère un profil comme un ensemble de droits. Pour un profil donné, je donne des droits d’accès à certaines rubriques dans l’espace privé, et des doits d’accès à certaines rubriques dans l’espace public. Comme il s’agit de droits d’accès, les rubriques concernées pour l’accès public et l’accès privé peuvent différer pour un même profil. Ensuite, les droits définis par un profil sont accordés par un auteur.

    Outre le fait qu’un profil peut accorder des droits différents sur l’espace public et dans l’interface privé, il en résulte que si un droit d’accès est donné à certaines rubriques sur l’espace public, alors ces mêmes rubriques ne sont plus accessibles aux personnes ne disposant pas de droits spécifiques sur elles. Autrement dit, les rubriques accessibles via un profil dépendent des définitions des autres profils. Si l’on prend l’image d’un immeuble, définir des profils consiste à poser des verrous sur des portes. Une fois le verrou posé, les personnes ne disposant pas de la clé ne peuvent plus passer. En même temps, en matière d’héritage des droits, ceux qui appartiennent à ce profil peuvent passer et continuer d’avancer jusqu’à ce qu’ils tombent sur un autre verrou qui aurait été posé par un autre profil. Les points d’entrée d’un profil constitue alors les points de sortie des autres profils.

    En terme de droits, le fait que les rubriques accessibles avec un profil dépendent des autres profils est déjà présent de manière intuitive dans Accès_restreint. En effet, lorsque que l’on définit une zone, on accorde des droits d’accès à cette zone et en même temps on en interdit l’accès aux autres zones. Les zones sont donc en l’état, déjà plus ou moins hybrides car elles sont à la fois un ensemble de rubriques et un ensemble de droits.

    La notion de profil que je développe ici induit un mécanisme assez proche de ce que j’avis proposé il y a quelques mois et peut donc être testé à l’aide du zip disponible ici : http://joseph.larmarange.net/Plugin.... ATTENTION : c’est un zip de dev qui utilise les mêmes tables que Accès Restreint. Ne pas activer Accès restreint en même temps et à n’utiliser que sur un site de test.

    Cette notion de profils n’interdit pas par la suite d’ajouter d’autres définition de droits.
    Comme un profil est un ensemble de droits et non un ensemble d’auteurs, rien n’interdit conceptullement que puisse être développer en parallèle un plugin de reconnaissance d’adresse IP qui attribue les droits définis à un profil à certaines adresses IP.

    Si l’on souhaite retrouver certaines fonctionnalité de accès restreint par groupe, outre le fait que l’on puisse accorder les droits définis dans un profil directement à un auteur, ces droits pourraient également être accordés directement à un statut d’auteur.

    Il me semble qu’il est possible ainsi d’avoir un outil relativement simple au final qui permettrait de faire la meme chose que la définition de zones d’un côté et la définition de groupes de l’autre.

    • La notion de profil est un élément intéressant...
      malheureusement, dans tout système il y aura toujours un utilisateur qui aura besoin d’un acces particulier, faut-il pour autant créer un profil spécifique pour lui ?

      Autre point que je souhaiterais aborder, en plus de la gestion des accès est la gestion des droits... peut être que « autoriser » pourrais être intégré lors du regroupement des plugins...

      Affaire à suivre...

    • Joseph tux

      Est-ce qu’une arborescence hierarchique n’est pas déjà, et simplement, un regroupement de regroupements nommés ?

      Je ne comprend pas bien cette question.

      Ou bien il y a une subtilité qui m’échappe ? ( je n’ai que des rudiments de culture informatique )

      Vision de simple utilisateur

    Répondre à ce message

  • 1

    Je vais parler pour ma paroisse (mais tout le monde fait ça non ?) Pourquoi ne pas donner la possibilité, toute simple, à Accès Restreint V2 de venir prendre ses visiteurs dans une table extérieur à spip ?

    Il faudrait juste pour ce cas indiquer le nom de la table, le nom du champ login et le nom du champ password.

    Je propose cela, car ici je gère déjà plus de 350 users avec une application tiers php/mysql qui change en permanence et cela pourrait éviter d’injecter des users doublons entre les tables.

    Merci de votre oreille attentive ;-)

    • Bonsoir
      J’ai exactement la même demande, c’est a dire de pouvoir utiliser une table externe. Aussi pourquoi ne pas le prévoir sous forme d’option complémentaire : soit l« annuaire » de Spip, soit une table externe. Tiens, soyons fous... les 2 à la fois !
      Car gérer 2 tables annuaires d’utilisateurs en parallèle nécessite trop de temps, et entraîne obligatoirement des erreurs, omissions ou pire des users qu’on oublie de supprimer !
      Alors soyez sympas quoi......

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom