Univention Bugzilla – Bug 28098
Umlaute in Policy-Namen verbieten
Last modified: 2012-12-12 21:08:02 CET
Über den DHCP-Wizard wurde direkt eine neue Richtlinie angelegt, deren Name ein Umlaut enthielt. Diese wurde dann zwar auch noch korrekt angelegt, aber nicht mit dem DHCP-Objekt verknüpft werden; beim Speichern wird folgende Fehlermeldung angezeigt: Benachrichtigung Das UDM-Objekt konnte nicht gespeichert werden. LDAP-FehlerInvalid syntax: univentionPolicyReference: value #0 invalid per syntax Bitte auch das fehlende Leerzeichen zwischen "LDAP-Fahler" und "Invalid syntax" beachten
Ich halte das nicht für "minor", wir sollten das zu 3.1 fixen. Das trat auch gerade in der Schulung auf für eine Richtlinie "München" und ist irritierend, weil man eher davon ausgeht, das mit dem Wert der Richtlinie etwas nicht stimmt. Umlaute sind ja im Deutsch nicht gerade exotisch und der Workaround keine Umlaute im Namen einer Richtlinie zu erlauben sollte nicht so aufwendig sein.
(In reply to comment #1) > ... > Umlaute sind ja im Deutsch nicht gerade exotisch und der Workaround keine > Umlaute im Namen einer Richtlinie zu erlauben sollte nicht so aufwendig sein. Das stimmt und sollte so umgesetzt werden.
univention-directory-manager-modules (8.0.33-1) unstable; urgency=low * added syntax for policy names to limit set of allowed characters (Bug #28098) svn 35817 Ich habe mal überprüft welche Zeichen hier zusätzlich zu Umlauten noch Probleme bereiten und eine Syntax für Policy Namen hinzugefügt um den Zeichensatz entsprechend zu limitieren. Die Syntaxreferenz wurde auch für alle policy Module angepasst. Erlaubt sind jetzt noch Buchstaben, Zahlen sowie die Zeichen ... ====================================================================== # ! $ % & / | ^ . * ~ - ======================================================================
univention-directory-manager-modules (8.0.35-1) unstable; urgency=low * allow "_" character in policy names (Bug #28098) svn 35821 Unterstrich ist nun ebenfalls erlaubt.
*** Bug 8824 has been marked as a duplicate of this bug. ***
*** Bug 18790 has been marked as a duplicate of this bug. ***
Leerzeichen sind jetzt auch erlaubt. univention-directory-manager-modules (8.0.52-1) unstable; urgency=low * allow blank charakters in policy names (Bug #28098) svn 36219
Die Fehlernachricht "May only contain ..." beinhaltet nicht "^". Im Deutschen würde ich nicht " und ", sondern " sowie " sagen. Klingt irgendwie besser. Außerdem: Wenn man schon mal dabei ist, eine richtige regex zu schreiben, dann sollte man bedenken, dass eine dn nicht mit den Sonderzeichen anfangen darf. Das ganze ist eine Verbesserung zu "string", aber trotzdem könnte man folgenden Namen abfangen: #!$%&/|^.*~_ - Außerdem scheint * im Namen dafür zu sorgen, dass referenzierte Objekte nicht im entsprechenden Tab der Policy auftauchen. Man kann die Policy anlegen, man kann sie verknüpfen, nur scheint die Suche nicht zu klappen. Keine Ahnung, ob man da einen Workaround finden kann, ich würde * einfach verbieten.
Leerzeichen (erlaubt sind auch Tabulatoren? Wer um alles in der Welt will den Tabulatoren im Namen?) am Ende eines Policynamens bitte auch verbieten. Einzeln scheint es zu funktionieren, anlegen, referenzieren, das ganze Programm. Aber Angezeigt werden sie immer ohne die Leerzeichen am Ende. Ich habs noch nicht ganz raus gekriegt, aber ich konnte zwei Objekte anlegen "x\t\t\t" und "x ", und am Ende kommt das hier: univention-ldapsearch -LLL objectClass=univentionPolicyPackagesMember dn: cn=x,cn=policies,dc=ucs31,dc=local,dc=test objectClass: top objectClass: univentionPolicy objectClass: univentionPolicyPackagesMember objectClass: univentionObject univentionObjectType: policies/memberpackages cn:: eAkJCQ== cn: x Das ist mit nicht ganz geheuer.
(In reply to comment #9) > Ich habs noch nicht ganz raus gekriegt, aber ich konnte zwei Objekte anlegen > "x\t\t\t" und "x ", und am Ende kommt das hier: Ersteres scheint übernommen worden zu sein, bei letzterem wurden die Leerzeichen gestripped. > dn: cn=x,cn=policies,dc=ucs31,dc=local,dc=test ... > cn:: eAkJCQ== > cn: x $ echo eAkJCQ== | base64 -d | xxd -g 1 0000000: 78 09 09 09 x... ASCII 0x09 = \t Ich will gar nicht wissen was passiert, wenn du ein Komma oder gar eine Policy "cn=foo,ou=bar" nennen willst. (vgl. Bug #18338, Bug #24758)
(In reply to comment #10) > (In reply to comment #9) > > Ich habs noch nicht ganz raus gekriegt, aber ich konnte zwei Objekte anlegen > > "x\t\t\t" und "x ", und am Ende kommt das hier: > > Ersteres scheint übernommen worden zu sein, bei letzterem wurden die > Leerzeichen gestripped. > > > dn: cn=x,cn=policies,dc=ucs31,dc=local,dc=test > ... > > cn:: eAkJCQ== > > cn: x > > $ echo eAkJCQ== | base64 -d | xxd -g 1 > 0000000: 78 09 09 09 x... > > ASCII 0x09 = \t > > Ich will gar nicht wissen was passiert, wenn du ein Komma oder gar eine Policy > "cn=foo,ou=bar" nennen willst. (vgl. Bug #18338, Bug #24758) = und , sind ja seit Neuestem in Policy-Namen verboten. In 3.0 gibts ein "No such object"...
univention-directory-manager-modules (8.0.54-1) unstable; urgency=low * Policy name: forbid "*", special characters at the beginning and space and the end (Bug #28098) svn 36247 "*" ist jetzt verboten. Statt Tabluatoren und Leerzeichen sollten nurnoch Leerzeichen funktionieren. Darüber hinaus dürfen Policynamen nurnoch mit Zahlen und Buchstaben beginnen und nicht mit Leerzeichen enden.
Funktionstest Ok Changelog Ok REOPEN, weil ich die Befürchtung habe, dass die Fehlermeldung zu Stirnrunzeln führt. Wenn ich eine Policy "München" nenne, dann habe ich doch nur Buchstaben verwendet, oder? Der ganze Bug wurde eigentlich nur wegen der Umlaute eröffnet. Man sollte explizit auf diese eingehen. "Umlauts are not allowed" oder "letters (except umlauts)" oder so etwas. Übrigens ist auch ß nicht erlaubt. Vielleicht sagt man alphanumeric, aber das versteht wohl auch nicht jeder. Ich denke mit "Umlaute" ist klar, dass auch ß nicht geht.
(In reply to comment #13) > Funktionstest Ok > Changelog Ok > > REOPEN, weil ich die Befürchtung habe, dass die Fehlermeldung zu Stirnrunzeln > führt. > > Wenn ich eine Policy "München" nenne, dann habe ich doch nur Buchstaben > verwendet, oder? Der ganze Bug wurde eigentlich nur wegen der Umlaute eröffnet. > Man sollte explizit auf diese eingehen. "Umlauts are not allowed" oder "letters > (except umlauts)" oder so etwas. Übrigens ist auch ß nicht erlaubt. Vielleicht > sagt man alphanumeric, aber das versteht wohl auch nicht jeder. Ich denke mit > "Umlaute" ist klar, dass auch ß nicht geht. Die Fehlermeldung wurde entsprechend angepasst. Allerdings ist jetzt die Übersetzung kaputt - und ich kann das Problem nicht identifzieren, daher -> Bug #28846. Dieser hier ist damit wieder FIXED.
VERIFIED
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".