Products.LDAPUserFolder è un sostituto per una cartella utente Zope. Non memorizzare i propri oggetti di utente, ma li costruisce al volo dopo l'autenticazione di un utente nel database LDAP.
Come aggiornare
L'aggiornamento comporta non solo il disimballaggio il nuovo codice, si dovrebbe anche eliminare e ricreare tutte le istanze LDAPUserFolder nell'installazione Zope per evitare errori. Una strategia di aggiornamento di sicurezza simile a questa:
& Nbsp; * il login come utente di emergenza
& Nbsp; * eliminare tutte le istanze LDAPUserFolder
& Nbsp; * aggiornare il prodotto filesystem
& Nbsp; * riavviare Zope
& Nbsp; * il login come utente di emergenza
& Nbsp; * ricreare le istanze LDAPUserFolder
Come creare un utente di emergenza è descritta nel documento SECURITY.txt nella cartella 'doc' alla radice della vostra installazione del software Zope. Lo script di cui 'zpasswd.py' si trova nella cartella 'bin' alla radice della vostra installazione Zope.
Problemi Debug
Tutti i messaggi di log vengono inviati per l'evento standard di Zope log 'event.log'. Per vedere l'uscita di registrazione più dettagliato è necessario aumentare il livello di log in zope.conf di Zope. Vedere la direttiva 'eventlog'. Impostare il tasto 'livello' a 'debug' ci permetterà di ottimizzare il login uscita e può aiutare a individuare i problemi durante l'installazione e il collaudo.
Perché il LDAPUserFolder non mostrare tutti i miei gruppi LDAP?
Secondo il feedback ricevuto da parte di persone che utilizzano i prodotti Netscape Directory il modo in cui un nuovo gruppo viene istanziato permette gruppi vuoti di esistere nel sistema. Tuttavia, secondo la definizione canonica per il gruppo registra gruppi devono sempre avere un attributo membro del gruppo. Il LDAPUserFolder cerca record di gruppo, cercando le voci dei membri del gruppo. Se un record gruppo non ha membri poi sarà saltato. Come detto in precedenza, questo sembra solo interessare i server di Netscape Directory. Per ovviare a questo (Netscape) fenomeno aggiungere uno o più membri del gruppo in questione, utilizzando gli strumenti forniti con il server di directory. Dovrebbe apparire nella LDAPUserFolder dopo.
Perché utilizzare LDAP per record utente negozio?
LDAP come fonte di record utente Zope è una scelta eccellente in molti casi, come ...
& Nbsp; * Hai già un setup LDAP esistente che può memorizzare i dati dei dipendenti aziendali e non si vuole duplicare tutti i dati in una cartella utente Zope
& Nbsp; * Si vuole fare lo stesso database di utenti disponibili ad altre applicazioni come la posta, client di rubrica, autenticatori sistema operativo (PAM-LDAP) o altri servizi di rete che consentono l'autenticazione contro LDAP
& Nbsp; * Sono disponibili diverse installazioni Zope che devono condividere i record utente o una configurazione ZEO
& Nbsp; * Si vuole essere in grado di memorizzare più di un semplice nome utente e password nella cartella utente Zope
& Nbsp; * Si vuole manipolare i dati degli utenti al di fuori di Zope
... L'elenco continua.
Il Schema LDAP
Il server LDAP deve contenere i record che possono essere utilizzati come record utente. Eventuali tipi di oggetti, come persona, organizationalPerson, o inetOrgPerson ed eventuali derivati dovrebbero funzionare. Record di tipo posixAccount dovrebbero funzionare correttamente pure. Il LDAPUserFolder aspetta i vostri record utente di avere almeno i seguenti attributi, la maggior parte delle quali sono necessari per le classi di oggetti di cui sopra, comunque:
& Nbsp; * un attributo per contenere l'ID utente (come CN, uid, etc)
& Nbsp; * userPassword (il campo password)
& Nbsp; * objectClass
& Nbsp; * qualunque attributo si sceglie come attributo di utente
& Nbsp; * attributi legate a una persona come al solito a roma sn (cognome), givenName (nome), uid o posta (indirizzo e-mail) farà lavorare con il LDAPUserFolder più bello
Utenti Zope hanno certi ruoli ad essi associati, questi ruoli determinare quali autorizzazioni utente deve. Per la LDAPUserFolder, informazioni ruolo può essere espressa attraverso l'appartenenza a raggruppare i record in LDAP.
Record di gruppo possono essere di qualsiasi tipo di oggetto che accetta più attributi di tipo "uniqueMember" o "membro" e che ha un attributo "cn". Un tale tipo è "groupOfUniqueNames". Il cn descrive il nome del gruppo / ruolo, mentre gli attributi membri indicano verso tutti i record utente che fanno parte di questo gruppo. Solo i record di gruppo in stile che utilizzano DNS per i suoi membri sono supportati, che esclude le classi come posixGroup.
Per esempi di gruppo- valido e user-record per LDAP vedere il SAMPLE_RECORDS.txt file in questa distribuzione. Ha campioni per un utente e un record di gruppo in formato LDIF.
E 'al di fuori del campo di applicazione di questa documentazione per descrivere le diverse classi di oggetti e attributi in dettaglio, si prega di consultare la documentazione LDAP per un trattamento migliore.
Cose da guardare fuori per
Dal momento che una cartella utente è uno di questi elementi che possono bloccare gli utenti con il proprio sito, se si rompono Suggerisco testare le impostazioni in una certa posizione poco visibile prima di sostituire la cartella acl_users principali di un sito con un LDAPUserFolder.
Come ultima risorsa sarete sempre in grado di accedere e apportare le modifiche del superutente (o più recenti versioni di Zope chiamato "utente di emergenza"), che, come bonus aggiuntivo, in grado di eliminare e creare cartelle utente. Questa è una violazione dello standard "superuser non può creare / proprio nulla" politica, ma può salvare la pelle in tanti modi.
Considerazioni dello schema LDAP quando viene utilizzato con il CMF
Il CMF (e per estensione, Plone) si aspettano che ogni utente ha un indirizzo di posta elettronica. Per far funzionare tutto correttamente i record utente LDAP deve avere un attributo "mail", e questo attributo deve essere impostato nella scheda "Schema LDAP" del vostro LDAPUserFolder. Quando si aggiunge la "mail" voce dello schema assicuratevi di impostare il campo "Mappa a Name" a "e-mail".
Gli attributi che appaiono sul modulo di iscrizione e la vista di personalizzazione sono disciplinate dalle proprietà che si 'Registrati' utilizzando la scheda 'Stati Properties' nello strumento portal_memberdata vista ZMI, che a sua volta proviene dalla scheda 'Schema LDAP' nel vista LDAPUserFolder ZMI. Gli attributi che si desidera attivare per i membri del portale deve essere impostato sulla scheda LDAPUserFolder 'LDAP Schema' prima, e poi registrato con schermo "Proprietà Membeer" nello strumento Dati del membro vista ZMI.
Cosa c'è di nuovo in questa versione:
- errore Fix python-ldap quando si riceve set invece di liste di attributi per cercare (Patch da Godefroid Chapelle)
- Alcune pulizie trovate da pyflakes ((Patch by Godefroid Chapelle)
Cosa c'è di nuovo in versione 2.24:
- Quando si confrontano un valore di login per accedere valori trovati sulla LDAP Server striscia il valore login prima. Questo segue comportamento OpenLDAP che considera valori corrisponde anche con finali o portano spazi nel filtro di query valore. (Https://bugs.launchpad.net/bugs/1060080)
- LDAPDelegate: Quando si utilizza un utente dalla macchine sicurezza Zope al fine di trovare un bind adatto DN e la password per la connessione a un server LDAP, disfarsene quando non è stato creato come il risultato di un vero e proprio login e quindi ha un password non valida (https://bugs.launchpad.net/bugs/1060112)
- utilizzare una serie nota di versioni dei componenti (versions.txt da Zope 2.3.18) per evitare di dover microgestire versioni di dipendenza
- voci di cambiamento di registro spostati per la versione 2.18 e anziani dal changes.txt a HISTORY.txt
- riformattare HISTORY.txt e fare riposare-compliant
- ripulire la formattazione di changes.txt
Cosa c'è di nuovo in versione 2.23:
- Aggiungi setuptools-git per setup_requires per impedire che i file mancanti nel rilascio di uova -. versioni 2.22 e 2.21 non costruirà a causa di una mancanza version.txt
Cosa c'è di nuovo in versione 2.20:
- Fix per CVE-2010-2944 (http: // secunia.com/advisories/cve_reference/CVE-2010-2944/), che non è mai riferito a monte dalla gente di Debian, che hanno trovato il problema 8 mesi fa (vedi http://bugs.debian.org/cgi-bin/bugreport .cgi? bug = 593.466). Grazie ragazzi.
Cosa c'è di nuovo in versione 2.19:
- Aggiungi nome attributo al negative_cache_key lo richiede per lo stesso valore, ma diverso attributo non avvelenare la cache. (Https://bugs.launchpad.net/bugs/695821)
- Le classi base mutate Zope 2.13 non definiscono isPrincipiaFolderish, quindi la cartella utente dovrebbe più visualizzati nel riquadro di navigazione a sinistra nella ZMI. (Https://bugs.launchpad.net/bugs/693315)
- Risolto un controllo difettoso per unicode così scadenza utente non avrà esito negativo se il valore unicode viene passato. Cambiato tutti i controlli per la stringa e unicode usare basestring. (Https://bugs.launchpad.net/bugs/700071)
- Risolto un errore di esportazione / importazione in modo prova tutte le prove vengono nuovamente.
- Il Gestore DN valore password nella scheda Configura nella ZMI presentò in chiaro durante la visualizzazione del codice sorgente HTML della pagina visualizzata. (Https://bugs.launchpad.net/bugs/664976)
Requisiti :
- Python
I commenti non trovato