{{important(The following content was migrated from the old Wiki. The content needs to be updated and is not fully reliable.)}}
Piraten-LDAP
Xarem_Nightslayer wird einen virtuellen Server auf seinem Root einrichten welcher für den Test genutzt werden kann.
Darauf wird installiert:
Damit werden wir das komplette Portal von der Piraten-Partei Schweiz nachbauen und Testdaten importieren.
Testumgebung (vServer Debian) aufsetzen OpenLDAP installieren Drupal, Wiki und Forum installieren LDAP Anbindung für Drupal, Wiki und Forum CiviCRM mit LDAP Anbindung installieren, konfigurieren
MediaWiki: xGhost
In paar Jahren wird PPS bereits paar Angestellte haben. Daher sollte die LDAP Struktur so aufgebaut werden, dass die User bereits mit vollen Adressangaben usw. ausgestattet werden. Nicht nur, wegen den späteren angestellten, sondern auch, damit wir nur eine Datenbank haben was die User anbelangt, sondern allgemein. Mit LDAP lässt sich so gut wie alles perfekt programmieren und kombinieren.
Daher schlägt Xarem vor:
Zuerst einmal sollten wir Drupal so konfigurieren, dass User spätestens beim nächsten Login Adresse usw. eingeben müssen. Ebenfalls (optional) Foren- und Wiki Benutzername und evtl. auch noch Jabber. Mitglieder zusätzlich Telefonnummer.
Danach sollten wir ein Script schreiben, welches unsere bisherigen Mitglieder mit den LDAP Usern vernetzt und den bestimmten User in eine OU hinzufügt.
So können wir genug Daten sammeln (nicht wie Google ;-) ) welche Zukunftssicher sind.
Montag, 26.10.2009 - 20:15
Wechseln zu: Navigation, Suche
MitgliederDB Sitzung mit: SciFi, Annubis, Corvus, SimonMoon, Simon Rupf
Das Team unter the3rdbit hat bisher einen LDAP Server aufgesetzt und begonnen, diesen zu konfigurieren. Zusätzlich ist CiviCRM mit Anbindung an Drupal geplant. Für mehr Details siehe [Mitglieder_DB/Protokoll_20091022].
Mitgliederverwaltung:
Anwesend:
Neu dabei: Corvus, ghoja
Sitzungsleitung: The3rdBIT
Protokoll: The3rdBIT
Aktuelles Hauptziel:
Folgende Teile des Projekts wurden als einzelne Module Abgekoppelt und vorerst pausiert:
Anforderungen an die Mitgliederverwaltung wird bis zur nächsten Sitzung entwickelt. 1. Version wird von The3rdBIT entwickelt.
Freitag 4. Dezember 20:00
Anwesend:
Entschuldigt:
Sitzungsleitung: The3rdBIT
Protokoll: The3rdBIT
Migrationsstrategie entwickeln:
Systemevaluation entwickeln:
"Grundkonzept der LDAP Struktur erstellen" auf nächste Woche verschoben
Mittwoch 9. Dezember 20:00
Anwesend:
Sitzungsleitung: The3rdBIT
Protokoll: The3rdBIT
Sonntag 13. Dezember 20:00
Anwesend:
Protokoll: Corvus Siehe auch Diskussion zu dieser Seite
LDAP-Struktur-Entwürfe von xGhost und Corvus. Die Unterschiede wurden Diskutiert und das Resultat ist in Mitglieder DB/LDAP Database Fields eingeflossen.
Nicht Definiert
Anwesend:
Protokoll: The3rdBIT
Die LDAP-Struktur von letzter Sitzung von xGhost und Corvus wurde einstimmig gutgeheissen.
Erfahrung mit LDAP haben nur Xarem_Nightslayer und xGhost, jedoch beide in den nächsten zwei Wochen keine Zeit dafür. Wenn bis in einer Woche niemand anderes gefunden wurde, wird die Realisierung der LDAP-DB bis dann verschoben.
In den nächsten zwei Wochen wird Corvus weitere Mitgliederverwaltungssysteme suchen sowie auswählen und The3rdBIT diese auf dem Testserver installieren und mit einer Versuchs-LDAP-Datenbank versehen.
In etwa 1 Woche wird also jeder von The3rdBIT die Zugangsdaten eines Testusers auf den bereits installierten Systemen erhalten.
In etwa 2 Wochen wird die nächste Sitzung zur Besprechung der Systeme stattfinden und wohl das weitere Vorgehen mit der LDAP-DB besprochen. Im neuen Mumble. Bitte vorher Client testen!
Anwesend:
Protokoll: The3rdBIT
Wegen Serverproblemen konnten wir uns nicht im offiziellen Server Treffen und sind auf apophis.ch ausgewichen. Wegen Verspätung und fehlenden Arbeitsgruppen Teilnehmern wurde es nur zu einer Info-Sitzung.
Corvus hat auf dem offiziellen Piraten-Testserver einige Systeme getestet. Dabei ist er zum Schluss gekommen, dass für die Mitgliederverwaltung die meisten der vorgeschlagenen Systeme auf Mitgliederverwaltung ausgerichtet sind. Diese sind entweder überfüllt mit für den Zweck unnötigen Funktionen oder zu fest auf Netzwerkbenutzer ausgelegt.
Corvus hat eine Kombination aus dem Drupal LDAP Verwaltungstool als Verwaltung und phpLDAPadmin als Exportprogramm für Reportings vorgeschlagen. Im Drupal müsste noch das Mapping auf die entsprechenden Felder im LDAP eingerichtet und zum Teil umprogrammiert werden und für Die Reportings wären noch einige Anpassungen nötig.
Anwesend:
Protokoll: Corvus
Am Samstag 13.03.2010 hatt ich mich mit dergringo getroffen und unter anderem über die Mitgliederdatenbank sowie die SSO-Infrastruktur gesprochen.
Information durch Corvus
Die mitgliederbezogenen Daten sind restlos alle in LDAP gespeichert und werden über ein noch zu programmierende Verwaltungsfrontend verwaltet.
Das Login für die diversen Services geschieht über ein zentrales Loginportal.
Das skizzierte Ziel wird in mehreren Stufen erreicht. Die Idee ist diese Umfangreiche Konstrukt in kleinen überschaubaren Häppchen Stück für Stück zusammen zu bauen.
Die vom Aktuar verwalteten Mitgliederdaten werden in die LDAP-Datenbank übertragen und vorerst über phpLDAPadmin verwaltet. Über Drupal haben die Mitglieder die Möglichkeit ihre Daten ein zu sehen und zu verändern. Eine automatische Anmeldung ist noch nicht möglich.
Drupal authentifiziert native gegen LDAP.
Die Gruppenstruktur wird vorerst noch nicht in LDAP abgebildet, sondern von den Gruppenadmins in Drupal mittels Organicgroups erstellt. Auf diese Weise können wir analysieren, wie sich diese die Organisation ihrer Gruppen vorstellen.
Definitionen der einzelnen Phasen müssen noch definiert werden.
Alle mitgliederbezogenen Daten inklusive der Organisationsstruktur (Gruppenzugehörigkeit) sind in LDAP abgebildet und werden über ein Verwaltungsfrontend administriert.
Dieses Frontend erlaubt auch Self-Service sowie Autoregistration.
Information durch Corvus
Meine Erfahrungen haben gezeigt, dass einige Änderungen an der Struktur und am Benutzerobjekt notwendig sind. Siehe Diskussion von LDAP Database Fields
Entschluss: Die Anpassung ist sinnvoll.
{{note(Sammlung von Informationen Ansätzen und Erweiterungen zur Authentifizierung von Benutzer in in Rails. Diese Informationen sollen als Grundlage für die Auswahl eines passenden Frameworks oder eines Lösungsansatzes dienen)}}
now that Rails 3 is out, Devise seems to be the new, new kid on the block
Authlogic is a clean, simple, and unobtrusive ruby authentication solution. Put simply, its the Chuck Norris of authentication solutions for your framework of choice.
h4 Helpful Links
" https://github.com/technoweenie/http_token_authentication
{{important(The following content was migrated from the old Wiki. The content needs to be updated and is not fully reliable.)}}
dc=piratenpartei,dc=ch | |---------- **dc=board** | _Roles for the board members on national level_ | _There is also a ppsGroup object for the GPK an the foundingmembers_ | |---------- **dc=members** | _Contains all Personen objects which are member on the national level_ | |---------- **dc=people** | _Contains all Personen objects which are no members an only used for the SSO_ | |---------- **dc=workgroups** | _Contains ppsGroup object for each workgroup on the national level_ | _Each group can contain several subgroups and roles_ | |---------- **st=[xx]** | _For each Section there is a ppsSection object containing the same structure as the top level_ | _Exception is the container dc=people which exists only on top level_ | dc=board | dc=members | dc=workgroups
| Objectclass | Description | rdn | attribute |
ppsContainer | General container | dc |
|---|---|---|---|---|---|---|
| ppsGroup | Workgroups | cn | ||||
| ppsPerson | uniqueIdentifier | |||||
| ppsRole | cn | |||||
| ppsSection | Section | st |
| Name | LDAP attribute | Values | Description |
|---|---|---|---|
| Name | dc | ||
| Description | description |
| Name | LDAP attribute | Values | Description |
|---|---|---|---|
| Name | dc | ||
| Category | businessCategory | 0 | Political |
| 1 | Operativ | ||
| Description | description | ||
| Link | labeledURI | Link to a webpage with additional Information to this object | |
| Members | member | dn | |
| Leader | owner | dn |
| Name | LDAP attribute | Values | Description |
|---|---|---|---|
| Name | dc | ||
| Description | description | ||
| Link | labeledURI | Link to a webpage with additional Information to this object | |
| E-mail address for this role if there is one. | |||
| Occupant | roleOccupant | dn |
| Name | LDAP attribute | Values | Description |
|---|---|---|---|
| Type | employeeType | 0 | Land Lubber (Sympathiser) |
| 1 | Sympathiser (Cabin Boy) | ||
| 2 | Pirate | ||
| 3 | Veteran | ||
| 8 | Walked the plank | ||
| 9 | Fleet | ||
| Nick | name | uid | |
| Identifier | uniqueIdentifier | Integer | Unique value to identifie this object. Only used for tecnical reason |
| Country | c | Two digit iso abbrevation | |
| Commonname | cn | gn sn | Concatenation of givenname and surname |
| Signature | description | Signature set by user used in Forum | |
| Member number | employeeNumber | Integer | |
| Givenname | givenName | ||
| Comment | info | Comment used by the administration | |
| Location | l | ||
| Mobile | mobile | ||
| Organization | o | ||
| Avatar | photo | Picture | Picture used in the forum |
| ZIP code | postalCode | ||
| Birth date | ppsBirthDate | generalizedtimstring | |
| Contribution class | ppsContributionClass | 0 | Normal |
| 1 | Reduced | ||
| Gender | ppsGender | 0 | Unknown |
| 1 | Male | ||
| 2 | Female | ||
| 9 | Not applicable | ||
| Joining date | ppsJoining | generalizedtimstring | Date at which the person joined the party |
| Leaving date | ppsLeaving | generalizedtimstring | Date at which the person left the party |
| Pivote cert | ppsPivoteCertID | Id of the Pivote Cert. | Used for revocation |
| Pivote cert valid until | ppsPivoteCertValidUntil | generalizedtimstring | Date at which the Pivot vert will become invalid |
| Notification method | ppsPreferredNotificationMethod | 0 | Letter |
| 1 | |||
| Voting right until | ppsVotingRightUntil | generalizedtimstring | Date at which the person will loss its voting right. |
| Preferred language | preferredLanguage | de | |
| de | |||
| fr | |||
| it | |||
| en | |||
| Surname | sn | ||
| State | st | Two digit abbrevation of the state. Only Switzerland. | |
| Street | street | ||
| Phone | telephoneNumber | ||
| Title | title | Academical titles as it should be be printed. | |
| Password | userPassword | Encrypted trought ssha |
{{note(Sammlung von Informationen zum versionieren Rails ActiveRecord Daten. Diese Informationen sollen dienen als Grundlage für die Auswahl eines passenden Frameworks)}}
http://stackoverflow.com/questions/1697456/versioning-of-models-in-ruby-on-rails
Always use the following format to create a new Formular
<fieldset>
<legend class="icon LEGEND_ICON_CLASS"><span>TITLE</span></legend>
<div class="form">
<%= label_tag :FIELD, "LABEL", :class=>"span-4" %>
<%= text_field_tag :FIELD %>
</div>
...
</fieldset>
The LEGEND_ICON_CLASS can be one of the following:
If you don't want an Icon, remove also the "icon" class from the class-Attribute.
TITLE is the Field-Group Heading. Attention, this has to be i18n compatible in future Versions
LABEL Label to show. Attention, this has to be i18n compatible in future Versions
FIELD is the Field from the model
The Submit-Button has to be defined this way:
<%= button_tag content_tag(:span, "LABEL"), :class=>"button round" %>
Or if you like an Icon:
<%= button_tag content_tag(:span, "LABEL", :class=>"icon BUTTON_ICON_CLASS"), :class=>"button round" %>
The BUTTON_ICON_CLASS is not used at the moment, but can be used in future to print an Icon onto the Button.
LABEL is the Label which is shown inside the Button
{{important(The following content was migrated from the old Wiki. The content needs to be updated and is not fully reliable.)}}
Für die Verwaltung der Mitgliederdaten soll ein Frontend geschaffen werden. Dieser Artikel dient der Erarbeitung des Pflichtenheftes für eine solche Applikation.
Die Mitgliederdaten sind in einer LDAP-Datenbank hinterlegt und wie unter LDAP Database Fields beschrieben strukturiert.
Es gibt vier Datensatztypen zu verwalten
Die Berechtigungen für Schreib- und Leserechte sind bis auf Feldebene in der Datenbank hinterlegt.
Alle Benutzereingabe werden verifiziert. Zum einen wird überprüft, ob die Eingabe in diesem Feld erlaubt ist, zum anderen soll überprüft werden, dass die Eingabe keinen Schadcode enthält.
Für die Erstellung eines Mitgliedereintrages gibt es zwei Szenarien.
Besteht bereits ein Datensatz unterhalb von "ou=dormant,ou=people,dc=piratenpartei,dc=ch" so wird dieser verwendet, wenn folgende Angaben übereinstimmen.
oder
Nach dem erstellen muss ein Workflow gestartet werden können (Information an vor definierte Personen)
Die Mitgliederdaten können zum einen von Autorisierten Personen bearbeitet werden und zum anderen kann jeder seinen eigenen Datensatz verändern. Autorisierte Personen sollen zudem die Möglichkeit haben Benutzer durch verschieben zwischen den entsprechenden Containern als Aktiv oder Inaktiv zu kennzeichnen. Inaktive Benutzer können sich nicht mehr anmelden.
Autorisierte Benutzer können neue Gruppen und Rollen erstellen und wieder löschen. Dabei sind sie in Abhängigkeit ihrer Autorisation auf bestimmte Teilbäume beschränkt. In gleicher Abhängigkeit können die Mitglieder den Gruppen oder Rollen zugewiesen werden oder von diesen wieder entfernt werden.
Für den Export sollen die Formate CSV sowie PDF zur Verfügung stehen.
Die Verbindung zum Frontend ist mittels SSL geschützt. Für den Zugang zum Self-Service reicht eine Autentifikation mittels Passwort. Für alles andere ist zusätzlich ein SSL-Client-Certificate notwendig.
phpLDAPadmin stellt grundsätzlich all geschilderten Funktionalitäten zur Verfügung. Dessen Frontend ist aber nicht für den Endbenutzer geeignet. Die Idee ist nun aufgesetzt auf phpLDAPadmin ein eigenes Frontend zu gestalten und wo immer möglich auf dessen Funktionen zurück zu greifen.
Die Anwendung basiert auf folgenden Techniken und Erweiterungen
Statischer Inhalt darf nicht von den Entwicklern gepflegt werden müssen. Darum müssen dien an und für sich statischen Seiten, dynamisch gehalten werden, damit diese von Autoren und Übersetzern gepflegt werden können.
Wird standardmässig von Rains unterstütz, zum aktuellen Zeitpunkt aber noch nicht verwendet.
Adressen, Telefonnummern, Mailadressen und URLs werden immer im Kontext eines anderen Objektes dargestellt und angepasst.
Enumerationen können sortiert werden un beeinflussen dadurch die Auflistung der Assoziierten Elemente in allen Views
Laden und darstellen von Sektionen, Gruppen und Rollen.
Managen von Mitgliedschaften in Rollen, Gruppen und Sektionen, sowie die Vertretungen von Organisationen
Einträge in die DB sollen erst nach der Validierung der E-Mailadresse stattfinden. Ein Memcache soll als semipersistenter Zwischenspeicher dienen.
Ebenfalls kann Chaching zu Performanz zwecken eingesetzt werden aber erst wenn unbedingt notwendig!
Die Suche soll so einfach wie möglich gestaltet werden. Dazu wird eine entsprechende Earchengine benötigt, damit ein einzelnes Suchfeld ausreicht um an alle der gewünschten Informationen zu kommen
Railscast bietet eine Serien von hochstehenden Screencast rund um Rail. Die folgende Liste enthält eine Sammlung von Techniken und Erweiterungen, welche für PirateAdmin interessant sein könnten.
http://fierce-day-7000.heroku.com
h2, Diverses