diff --git a/LICENSE b/LICENSE new file mode 100644 --- /dev/null +++ b/LICENSE @@ -0,0 +1,27 @@ +Copyright (c) Radoslav Dorcik 2009 + +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. +3. Neither the name of the author nor the names of his contributors + may be used to endorse or promote products derived from this software + without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +SUCH DAMAGE. diff --git a/Setup.hs b/Setup.hs new file mode 100644 --- /dev/null +++ b/Setup.hs @@ -0,0 +1,2 @@ +import Distribution.Simple +main = defaultMain diff --git a/doc/rfc2253.txt b/doc/rfc2253.txt new file mode 100644 --- /dev/null +++ b/doc/rfc2253.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group M. Wahl +Request for Comments: 2253 Critical Angle Inc. +Obsoletes: 1779 S. Kille +Category: Standards Track Isode Ltd. + T. Howes + Netscape Communications Corp. + December 1997 + + + Lightweight Directory Access Protocol (v3): + UTF-8 String Representation of Distinguished Names + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1997). All Rights Reserved. + +IESG Note + + This document describes a directory access protocol that provides + both read and update access. Update access requires secure + authentication, but this document does not mandate implementation of + any satisfactory authentication mechanisms. + + In accordance with RFC 2026, section 4.4.1, this specification is + being approved by IESG as a Proposed Standard despite this + limitation, for the following reasons: + + a. to encourage implementation and interoperability testing of + these protocols (with or without update access) before they + are deployed, and + + b. to encourage deployment and use of these protocols in read-only + applications. (e.g. applications where LDAPv3 is used as + a query language for directories which are updated by some + secure mechanism other than LDAP), and + + c. to avoid delaying the advancement and deployment of other Internet + standards-track protocols which require the ability to query, but + not update, LDAPv3 directory servers. + + + + +Wahl, et. al. Proposed Standard [Page 1] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + + Readers are hereby warned that until mandatory authentication + mechanisms are standardized, clients and servers written according to + this specification which make use of update functionality are + UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION + IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. + + Implementors are hereby discouraged from deploying LDAPv3 clients or + servers which implement the update functionality, until a Proposed + Standard for mandatory authentication in LDAPv3 has been approved and + published as an RFC. + +Abstract + + The X.500 Directory uses distinguished names as the primary keys to + entries in the directory. Distinguished Names are encoded in ASN.1 + in the X.500 Directory protocols. In the Lightweight Directory + Access Protocol, a string representation of distinguished names is + transferred. This specification defines the string format for + representing names, which is designed to give a clean representation + of commonly used distinguished names, while being able to represent + any distinguished name. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [6]. + +1. Background + + This specification assumes familiarity with X.500 [1], and the + concept of Distinguished Name. It is important to have a common + format to be able to unambiguously represent a distinguished name. + The primary goal of this specification is ease of encoding and + decoding. A secondary goal is to have names that are human readable. + It is not expected that LDAP clients with a human user interface + would display these strings directly to the user, but would most + likely be performing translations (such as expressing attribute type + names in one of the local national languages). + +2. Converting DistinguishedName from ASN.1 to a String + + In X.501 [2] the ASN.1 structure of distinguished name is defined as: + + DistinguishedName ::= RDNSequence + + RDNSequence ::= SEQUENCE OF RelativeDistinguishedName + + + + + + +Wahl, et. al. Proposed Standard [Page 2] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + + RelativeDistinguishedName ::= SET SIZE (1..MAX) OF + AttributeTypeAndValue + + AttributeTypeAndValue ::= SEQUENCE { + type AttributeType, + value AttributeValue } + + The following sections define the algorithm for converting from an + ASN.1 structured representation to a UTF-8 string representation. + +2.1. Converting the RDNSequence + + If the RDNSequence is an empty sequence, the result is the empty or + zero length string. + + Otherwise, the output consists of the string encodings of each + RelativeDistinguishedName in the RDNSequence (according to 2.2), + starting with the last element of the sequence and moving backwards + toward the first. + + The encodings of adjoining RelativeDistinguishedNames are separated + by a comma character (',' ASCII 44). + +2.2. Converting RelativeDistinguishedName + + When converting from an ASN.1 RelativeDistinguishedName to a string, + the output consists of the string encodings of each + AttributeTypeAndValue (according to 2.3), in any order. + + Where there is a multi-valued RDN, the outputs from adjoining + AttributeTypeAndValues are separated by a plus ('+' ASCII 43) + character. + +2.3. Converting AttributeTypeAndValue + + The AttributeTypeAndValue is encoded as the string representation of + the AttributeType, followed by an equals character ('=' ASCII 61), + followed by the string representation of the AttributeValue. The + encoding of the AttributeValue is given in section 2.4. + + If the AttributeType is in a published table of attribute types + associated with LDAP [4], then the type name string from that table + is used, otherwise it is encoded as the dotted-decimal encoding of + the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is + described in [3]. As an example, strings for a few of the attribute + types frequently seen in RDNs include: + + + + + +Wahl, et. al. Proposed Standard [Page 3] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + + String X.500 AttributeType + ------------------------------ + CN commonName + L localityName + ST stateOrProvinceName + O organizationName + OU organizationalUnitName + C countryName + STREET streetAddress + DC domainComponent + UID userid + +2.4. Converting an AttributeValue from ASN.1 to a String + + If the AttributeValue is of a type which does not have a string + representation defined for it, then it is simply encoded as an + octothorpe character ('#' ASCII 35) followed by the hexadecimal + representation of each of the bytes of the BER encoding of the X.500 + AttributeValue. This form SHOULD be used if the AttributeType is of + the dotted-decimal form. + + Otherwise, if the AttributeValue is of a type which has a string + representation, the value is converted first to a UTF-8 string + according to its syntax specification (see for example section 6 of + [4]). + + If the UTF-8 string does not have any of the following characters + which need escaping, then that string can be used as the string + representation of the value. + + o a space or "#" character occurring at the beginning of the + string + + o a space character occurring at the end of the string + + o one of the characters ",", "+", """, "\", "<", ">" or ";" + + Implementations MAY escape other characters. + + If a character to be escaped is one of the list shown above, then it + is prefixed by a backslash ('\' ASCII 92). + + Otherwise the character to be escaped is replaced by a backslash and + two hex digits, which form a single byte in the code of the + character. + + Examples of the escaping mechanism are shown in section 5. + + + + +Wahl, et. al. Proposed Standard [Page 4] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + +3. Parsing a String back to a Distinguished Name + + The structure of the string is specified in a BNF grammar, based on + the grammar defined in RFC 822 [5]. Server implementations parsing a + DN string generated by an LDAPv2 client MUST also accept (and ignore) + the variants given in section 4 of this document. + +distinguishedName = [name] ; may be empty string + +name = name-component *("," name-component) + +name-component = attributeTypeAndValue *("+" attributeTypeAndValue) + +attributeTypeAndValue = attributeType "=" attributeValue + +attributeType = (ALPHA 1*keychar) / oid +keychar = ALPHA / DIGIT / "-" + +oid = 1*DIGIT *("." 1*DIGIT) + +attributeValue = string + +string = *( stringchar / pair ) + / "#" hexstring + / QUOTATION *( quotechar / pair ) QUOTATION ; only from v2 + +quotechar = + +special = "," / "=" / "+" / "<" / ">" / "#" / ";" + +pair = "\" ( special / "\" / QUOTATION / hexpair ) +stringchar = + +hexstring = 1*hexpair +hexpair = hexchar hexchar + +hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" + / "a" / "b" / "c" / "d" / "e" / "f" + +ALPHA = + ; (decimal 65-90 and 97-122) +DIGIT = ; (decimal 48-57) +QUOTATION = + + + + + + + + +Wahl, et. al. Proposed Standard [Page 5] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + +4. Relationship with RFC 1779 and LDAPv2 + + The syntax given in this document is more restrictive than the syntax + in RFC 1779. Implementations parsing a string generated by an LDAPv2 + client MUST accept the syntax of RFC 1779. Implementations MUST NOT, + however, generate any of the RFC 1779 encodings which are not + described above in section 2. + + Implementations MUST allow a semicolon character to be used instead + of a comma to separate RDNs in a distinguished name, and MUST also + allow whitespace characters to be present on either side of the comma + or semicolon. The whitespace characters are ignored, and the + semicolon replaced with a comma. + + Implementations MUST allow an oid in the attribute type to be + prefixed by one of the character strings "oid." or "OID.". + + Implementations MUST allow for space (' ' ASCII 32) characters to be + present between name-component and ',', between attributeTypeAndValue + and '+', between attributeType and '=', and between '=' and + attributeValue. These space characters are ignored when parsing. + + Implementations MUST allow a value to be surrounded by quote ('"' + ASCII 34) characters, which are not part of the value. Inside the + quoted value, the following characters can occur without any + escaping: + + ",", "=", "+", "<", ">", "#" and ";" + +5. Examples + + This notation is designed to be convenient for common forms of name. + This section gives a few examples of distinguished names written + using this notation. First is a name containing three relative + distinguished names (RDNs): + + CN=Steve Kille,O=Isode Limited,C=GB + + Here is an example name containing three RDNs, in which the first RDN + is multi-valued: + + OU=Sales+CN=J. Smith,O=Widget Inc.,C=US + + This example shows the method of quoting of a comma in an + organization name: + + CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB + + + + +Wahl, et. al. Proposed Standard [Page 6] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + + An example name in which a value contains a carriage return + character: + + CN=Before\0DAfter,O=Test,C=GB + + An example name in which an RDN was of an unrecognized type. The + value is the BER encoding of an OCTET STRING containing two bytes + 0x48 and 0x69. + + 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB + + Finally, an example of an RDN surname value consisting of 5 letters: + + Unicode Letter Description 10646 code UTF-8 Quoted + =============================== ========== ====== ======= + LATIN CAPITAL LETTER L U0000004C 0x4C L + LATIN SMALL LETTER U U00000075 0x75 u + LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D + LATIN SMALL LETTER I U00000069 0x69 i + LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87 + + Could be written in printable ASCII (useful for debugging purposes): + + SN=Lu\C4\8Di\C4\87 + +6. References + + [1] The Directory -- overview of concepts, models and services. + ITU-T Rec. X.500(1993). + + [2] The Directory -- Models. ITU-T Rec. X.501(1993). + + [3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight + Directory Access Protocol (v3): Attribute Syntax Definitions", + RFC 2252, December 1997. + + [5] Crocker, D., "Standard of the Format of ARPA-Internet Text + Messages", STD 11, RFC 822, August 1982. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119. + + + + + + + +Wahl, et. al. Proposed Standard [Page 7] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + +7. Security Considerations + +7.1. Disclosure + + Distinguished Names typically consist of descriptive information + about the entries they name, which can be people, organizations, + devices or other real-world objects. This frequently includes some + of the following kinds of information: + + - the common name of the object (i.e. a person's full name) + - an email or TCP/IP address + - its physical location (country, locality, city, street address) + - organizational attributes (such as department name or affiliation) + + Most countries have privacy laws regarding the publication of + information about people. + +7.2. Use of Distinguished Names in Security Applications + + The transformations of an AttributeValue value from its X.501 form to + an LDAP string representation are not always reversible back to the + same BER or DER form. An example of a situation which requires the + DER form of a distinguished name is the verification of an X.509 + certificate. + + For example, a distinguished name consisting of one RDN with one AVA, + in which the type is commonName and the value is of the TeletexString + choice with the letters 'Sam' would be represented in LDAP as the + string CN=Sam. Another distinguished name in which the value is + still 'Sam' but of the PrintableString choice would have the same + representation CN=Sam. + + Applications which require the reconstruction of the DER form of the + value SHOULD NOT use the string representation of attribute syntaxes + when converting a distinguished name to the LDAP format. Instead, + they SHOULD use the hexadecimal form prefixed by the octothorpe ('#') + as described in the first paragraph of section 2.4. + +8. Authors' Addresses + + Mark Wahl + Critical Angle Inc. + 4815 W. Braker Lane #502-385 + Austin, TX 78759 + USA + + EMail: M.Wahl@critical-angle.com + + + + +Wahl, et. al. Proposed Standard [Page 8] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + + Steve Kille + Isode Ltd. + The Dome + The Square + Richmond, Surrey + TW9 1DT + England + + Phone: +44-181-332-9091 + EMail: S.Kille@ISODE.COM + + + Tim Howes + Netscape Communications Corp. + 501 E. Middlefield Rd, MS MV068 + Mountain View, CA 94043 + USA + + Phone: +1 650 937-3419 + EMail: howes@netscape.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wahl, et. al. Proposed Standard [Page 9] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (1997). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Wahl, et. al. Proposed Standard [Page 10] + diff --git a/doc/rfc2849.txt b/doc/rfc2849.txt new file mode 100644 --- /dev/null +++ b/doc/rfc2849.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group G. Good +Request for Comments: 2849 iPlanet e-commerce Solutions +Category: Standards Track June 2000 + + + The LDAP Data Interchange Format (LDIF) - Technical Specification + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document describes a file format suitable for describing + directory information or modifications made to directory information. + The file format, known as LDIF, for LDAP Data Interchange Format, is + typically used to import and export directory information between + LDAP-based directory servers, or to describe a set of changes which + are to be applied to a directory. + +Background and Intended Usage + + There are a number of situations where a common interchange format is + desirable. For example, one might wish to export a copy of the + contents of a directory server to a file, move that file to a + different machine, and import the contents into a second directory + server. + + Additionally, by using a well-defined interchange format, development + of data import tools from legacy systems is facilitated. A fairly + simple set of tools written in awk or perl can, for example, convert + a database of personnel information into an LDIF file. This file can + then be imported into a directory server, regardless of the internal + database representation the target directory server uses. + + The LDIF format was originally developed and used in the University + of Michigan LDAP implementation. The first use of LDIF was in + describing directory entries. Later, the format was expanded to + allow representation of changes to directory entries. + + + + +Good Standards Track [Page 1] + +RFC 2849 LDAP Data Interchange Format June 2000 + + + Relationship to the application/directory MIME content-type: + + The application/directory MIME content-type [1] is a general + framework and format for conveying directory information, and is + independent of any particular directory service. The LDIF format is + a simpler format which is perhaps easier to create, and may also be + used, as noted, to describe a set of changes to be applied to a + directory. + + The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT" + used in this document are to be interpreted as described in [7]. + +Definition of the LDAP Data Interchange Format + + The LDIF format is used to convey directory information, or a + description of a set of changes made to directory entries. An LDIF + file consists of a series of records separated by line separators. A + record consists of a sequence of lines describing a directory entry, + or a sequence of lines describing a set of changes to a directory + entry. An LDIF file specifies a set of directory entries, or a set + of changes to be applied to directory entries, but not both. + + There is a one-to-one correlation between LDAP operations that modify + the directory (add, delete, modify, and modrdn), and the types of + changerecords described below ("add", "delete", "modify", and + "modrdn" or "moddn"). This correspondence is intentional, and + permits a straightforward translation from LDIF changerecords to + protocol operations. + +Formal Syntax Definition of LDIF + + The following definition uses the augmented Backus-Naur Form + specified in RFC 2234 [2]. + +ldif-file = ldif-content / ldif-changes + +ldif-content = version-spec 1*(1*SEP ldif-attrval-record) + +ldif-changes = version-spec 1*(1*SEP ldif-change-record) + +ldif-attrval-record = dn-spec SEP 1*attrval-spec + +ldif-change-record = dn-spec SEP *control changerecord + +version-spec = "version:" FILL version-number + + + + + + +Good Standards Track [Page 2] + +RFC 2849 LDAP Data Interchange Format June 2000 + + +version-number = 1*DIGIT + ; version-number MUST be "1" for the + ; LDIF format described in this document. + +dn-spec = "dn:" (FILL distinguishedName / + ":" FILL base64-distinguishedName) + +distinguishedName = SAFE-STRING + ; a distinguished name, as defined in [3] + +base64-distinguishedName = BASE64-UTF8-STRING + ; a distinguishedName which has been base64 + ; encoded (see note 10, below) + +rdn = SAFE-STRING + ; a relative distinguished name, defined as + ; in [3] + +base64-rdn = BASE64-UTF8-STRING + ; an rdn which has been base64 encoded (see + ; note 10, below) + +control = "control:" FILL ldap-oid ; controlType + 0*1(1*SPACE ("true" / "false")) ; criticality + 0*1(value-spec) ; controlValue + SEP + ; (See note 9, below) + +ldap-oid = 1*DIGIT 0*1("." 1*DIGIT) + ; An LDAPOID, as defined in [4] + +attrval-spec = AttributeDescription value-spec SEP + +value-spec = ":" ( FILL 0*1(SAFE-STRING) / + ":" FILL (BASE64-STRING) / + "<" FILL url) + ; See notes 7 and 8, below + +url = + ; (See Note 6, below) + +AttributeDescription = AttributeType [";" options] + ; Definition taken from [4] + +AttributeType = ldap-oid / (ALPHA *(attr-type-chars)) + +options = option / (option ";" options) + + + +Good Standards Track [Page 3] + +RFC 2849 LDAP Data Interchange Format June 2000 + + +option = 1*opt-char + +attr-type-chars = ALPHA / DIGIT / "-" + +opt-char = attr-type-chars + +changerecord = "changetype:" FILL + (change-add / change-delete / + change-modify / change-moddn) + +change-add = "add" SEP 1*attrval-spec + +change-delete = "delete" SEP + +change-moddn = ("modrdn" / "moddn") SEP + "newrdn:" ( FILL rdn / + ":" FILL base64-rdn) SEP + "deleteoldrdn:" FILL ("0" / "1") SEP + 0*1("newsuperior:" + ( FILL distinguishedName / + ":" FILL base64-distinguishedName) SEP) + +change-modify = "modify" SEP *mod-spec + +mod-spec = ("add:" / "delete:" / "replace:") + FILL AttributeDescription SEP + *attrval-spec + "-" SEP + +SPACE = %x20 + ; ASCII SP, space + +FILL = *SPACE + +SEP = (CR LF / LF) + +CR = %x0D + ; ASCII CR, carriage return + +LF = %x0A + ; ASCII LF, line feed + +ALPHA = %x41-5A / %x61-7A + ; A-Z / a-z + +DIGIT = %x30-39 + ; 0-9 + + + + +Good Standards Track [Page 4] + +RFC 2849 LDAP Data Interchange Format June 2000 + + +UTF8-1 = %x80-BF + +UTF8-2 = %xC0-DF UTF8-1 + +UTF8-3 = %xE0-EF 2UTF8-1 + +UTF8-4 = %xF0-F7 3UTF8-1 + +UTF8-5 = %xF8-FB 4UTF8-1 + +UTF8-6 = %xFC-FD 5UTF8-1 + +SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F + ; any value <= 127 decimal except NUL, LF, + ; and CR + +SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / + %x21-39 / %x3B / %x3D-7F + ; any value <= 127 except NUL, LF, CR, + ; SPACE, colon (":", ASCII 58 decimal) + ; and less-than ("<" , ASCII 60 decimal) + +SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR] + +UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / + UTF8-4 / UTF8-5 / UTF8-6 + +UTF8-STRING = *UTF8-CHAR + +BASE64-UTF8-STRING = BASE64-STRING + ; MUST be the base64 encoding of a + ; UTF8-STRING + +BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A / + %x61-7A + ; +, /, 0-9, =, A-Z, and a-z + ; as specified in [5] + +BASE64-STRING = [*(BASE64-CHAR)] + + + Notes on LDIF Syntax + + 1) For the LDIF format described in this document, the version + number MUST be "1". If the version number is absent, + implementations MAY choose to interpret the contents as an + older LDIF file format, supported by the University of + Michigan ldap-3.3 implementation [8]. + + + +Good Standards Track [Page 5] + +RFC 2849 LDAP Data Interchange Format June 2000 + + + 2) Any non-empty line, including comment lines, in an LDIF file + MAY be folded by inserting a line separator (SEP) and a SPACE. + Folding MUST NOT occur before the first character of the line. + In other words, folding a line into two lines, the first of + which is empty, is not permitted. Any line that begins with a + single space MUST be treated as a continuation of the previous + (non-empty) line. When joining folded lines, exactly one space + character at the beginning of each continued line must be + discarded. Implementations SHOULD NOT fold lines in the middle + of a multi-byte UTF-8 character. + + 3) Any line that begins with a pound-sign ("#", ASCII 35) is a + comment line, and MUST be ignored when parsing an LDIF file. + + 4) Any dn or rdn that contains characters other than those + defined as "SAFE-UTF8-CHAR", or begins with a character other + than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be + base-64 encoded. Other values MAY be base-64 encoded. Any + value that contains characters other than those defined as + "SAFE-CHAR", or begins with a character other than those + defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. + Other values MAY be base-64 encoded. + + 5) When a zero-length attribute value is to be included directly + in an LDIF file, it MUST be represented as + AttributeDescription ":" FILL SEP. For example, "seeAlso:" + followed by a newline represents a zero-length "seeAlso" + attribute value. It is also permissible for the value + referred to by a URL to be of zero length. + + 6) When a URL is specified in an attrval-spec, the following + conventions apply: + + a) Implementations SHOULD support the file:// URL format. The + contents of the referenced file are to be included verbatim + in the interpreted output of the LDIF file. + b) Implementations MAY support other URL formats. The + semantics associated with each supported URL will be + documented in an associated Applicability Statement. + + 7) Distinguished names, relative distinguished names, and + attribute values of DirectoryString syntax MUST be valid UTF-8 + strings. Implementations that read LDIF MAY interpret files + in which these entities are stored in some other character set + encoding, but implementations MUST NOT generate LDIF content + which does not contain valid UTF-8 data. + + + + + +Good Standards Track [Page 6] + +RFC 2849 LDAP Data Interchange Format June 2000 + + + 8) Values or distinguished names that end with SPACE SHOULD be + base-64 encoded. + + 9) When controls are included in an LDIF file, implementations + MAY choose to ignore some or all of them. This may be + necessary if the changes described in the LDIF file are being + sent on an LDAPv2 connection (LDAPv2 does not support + controls), or the particular controls are not supported by the + remote server. If the criticality of a control is "true", then + the implementation MUST either include the control, or MUST + NOT send the operation to a remote server. + + 10) When an attrval-spec, distinguishedName, or rdn is base64- + encoded, the encoding rules specified in [5] are used with the + following exceptions: a) The requirement that base64 output + streams must be represented as lines of no more than 76 + characters is removed. Lines in LDIF files may only be folded + according to the folding rules described in note 2, above. b) + Base64 strings in [5] may contain characters other than those + defined in BASE64-CHAR, and are ignored. LDIF does not permit + any extraneous characters, other than those used for line + folding. + +Examples of LDAP Data Interchange Format + +Example 1: An simple LDAP file with two entries + +version: 1 +dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com +objectclass: top +objectclass: person +objectclass: organizationalPerson +cn: Barbara Jensen +cn: Barbara J Jensen +cn: Babs Jensen +sn: Jensen +uid: bjensen +telephonenumber: +1 408 555 1212 +description: A big sailing fan. + +dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com +objectclass: top +objectclass: person +objectclass: organizationalPerson +cn: Bjorn Jensen +sn: Jensen +telephonenumber: +1 408 555 1212 + + + + +Good Standards Track [Page 7] + +RFC 2849 LDAP Data Interchange Format June 2000 + + +Example 2: A file containing an entry with a folded attribute value + +version: 1 +dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com +objectclass:top +objectclass:person +objectclass:organizationalPerson +cn:Barbara Jensen +cn:Barbara J Jensen +cn:Babs Jensen +sn:Jensen +uid:bjensen +telephonenumber:+1 408 555 1212 +description:Babs is a big sailing fan, and travels extensively in sea + rch of perfect sailing conditions. +title:Product Manager, Rod and Reel Division + +Example 3: A file containing a base-64-encoded value + +version: 1 +dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com +objectclass: top +objectclass: person +objectclass: organizationalPerson +cn: Gern Jensen +cn: Gern O Jensen +sn: Jensen +uid: gernj +telephonenumber: +1 408 555 1212 +description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl +IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG +VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg +b3V0IG1vcmUu + +Example 4: A file containing an entries with UTF-8-encoded attribute +values, including language tags. Comments indicate the contents +of UTF-8-encoded attributes and distinguished names. + +version: 1 +dn:: b3U95Za25qWt6YOoLG89QWlyaXVz +# dn:: ou=,o=Airius +objectclass: top +objectclass: organizationalUnit +ou:: 5Za25qWt6YOo +# ou:: +ou;lang-ja:: 5Za25qWt6YOo +# ou;lang-ja:: +ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2 + + + +Good Standards Track [Page 8] + +RFC 2849 LDAP Data Interchange Format June 2000 + + +# ou;lang-ja:: +ou;lang-en: Sales +description: Japanese office + +dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz +# dn:: uid=,ou=,o=Airius +userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM= +objectclass: top +objectclass: person +objectclass: organizationalPerson +objectclass: inetOrgPerson +uid: rogasawara +mail: rogasawara@airius.co.jp +givenname;lang-ja:: 44Ot44OJ44OL44O8 +# givenname;lang-ja:: +sn;lang-ja:: 5bCP56yg5Y6f +# sn;lang-ja:: +cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA== +# cn;lang-ja:: +title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw== +# title;lang-ja:: +preferredlanguage: ja +givenname:: 44Ot44OJ44OL44O8 +# givenname:: +sn:: 5bCP56yg5Y6f +# sn:: +cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA== +# cn:: +title:: 5Za25qWt6YOoIOmDqOmVtw== +# title:: +givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8 +# givenname;lang-ja;phonetic:: + +sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ +# sn;lang-ja;phonetic:: +cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA== +# cn;lang-ja;phonetic:: +title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg== +# title;lang-ja;phonetic:: +# +givenname;lang-en: Rodney +sn;lang-en: Ogasawara +cn;lang-en: Rodney Ogasawara +title;lang-en: Sales, Director + + + + + + + +Good Standards Track [Page 9] + +RFC 2849 LDAP Data Interchange Format June 2000 + + +Example 5: A file containing a reference to an external file + +version: 1 +dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com +objectclass: top +objectclass: person +objectclass: organizationalPerson +cn: Horatio Jensen + +cn: Horatio N Jensen +sn: Jensen +uid: hjensen +telephonenumber: +1 408 555 1212 +jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg + +Example 6: A file containing a series of change records and comments + +version: 1 +# Add a new entry +dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com +changetype: add +objectclass: top +objectclass: person +objectclass: organizationalPerson +cn: Fiona Jensen +sn: Jensen +uid: fiona +telephonenumber: +1 408 555 1212 +jpegphoto:< file:///usr/local/directory/photos/fiona.jpg + +# Delete an existing entry +dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com +changetype: delete + +# Modify an entry's relative distinguished name +dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com +changetype: modrdn +newrdn: cn=Paula Jensen +deleteoldrdn: 1 + +# Rename an entry and move all of its children to a new location in +# the directory tree (only implemented by LDAPv3 servers). +dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com +changetype: modrdn +newrdn: ou=Product Development Accountants +deleteoldrdn: 0 +newsuperior: ou=Accounting, dc=airius, dc=com + + + + +Good Standards Track [Page 10] + +RFC 2849 LDAP Data Interchange Format June 2000 + + +# Modify an entry: add an additional value to the postaladdress +# attribute, completely delete the description attribute, replace +# the telephonenumber attribute with two values, and delete a specific +# value from the facsimiletelephonenumber attribute +dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com +changetype: modify +add: postaladdress +postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086 +- + +delete: description +- +replace: telephonenumber +telephonenumber: +1 408 555 1234 +telephonenumber: +1 408 555 5678 +- +delete: facsimiletelephonenumber +facsimiletelephonenumber: +1 408 555 9876 +- + +# Modify an entry: replace the postaladdress attribute with an empty +# set of values (which will cause the attribute to be removed), and +# delete the entire description attribute. Note that the first will +# always succeed, while the second will only succeed if at least +# one value for the description attribute is present. +dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com +changetype: modify +replace: postaladdress +- +delete: description +- + +Example 7: An LDIF file containing a change record with a control +version: 1 +# Delete an entry. The operation will attach the LDAPv3 +# Tree Delete Control defined in [9]. The criticality +# field is "true" and the controlValue field is +# absent, as required by [9]. +dn: ou=Product Development, dc=airius, dc=com +control: 1.2.840.113556.1.4.805 true +changetype: delete + + + + + + + + + + +Good Standards Track [Page 11] + +RFC 2849 LDAP Data Interchange Format June 2000 + + +Security Considerations + + Given typical directory applications, an LDIF file is likely to + contain sensitive personal data. Appropriate measures should be + taken to protect the privacy of those persons whose data is contained + in an LDIF file. + + Since ":<" directives can cause external content to be included when + processing an LDIF file, one should be cautious of accepting LDIF + files from external sources. A "trojan" LDIF file could name a file + with sensitive contents and cause it to be included in a directory + entry, which a hostile entity could read via LDAP. + + LDIF does not provide any method for carrying authentication + information with an LDIF file. Users of LDIF files must take care to + verify the integrity of an LDIF file received from an external + source. + +Acknowledgments + + The LDAP Interchange Format was developed as part of the University + of Michigan LDAP reference implementation, and was developed by Tim + Howes, Mark Smith, and Gordon Good. It is based in part upon work + supported by the National Science Foundation under Grant No. NCR- + 9416667. + + Members of the IETF LDAP Extensions Working group provided many + helpful suggestions. In particular, Hallvard B. Furuseth of the + University of Oslo made many significant contributions to this + document, including a thorough review and rewrite of the BNF. + +References + + [1] Howes, T. and M. Smith, "A MIME Content-Type for Directory + Information", RFC 2425, September 1998. + + [2] Crocker, D., and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [3] Wahl, M., Kille, S. and T. Howes, "A String Representation of + Distinguished Names", RFC 2253, December 1997. + + [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access + Protocol (v3)", RFC 2251, July 1997. + + [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + + +Good Standards Track [Page 12] + +RFC 2849 LDAP Data Interchange Format June 2000 + + + [6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform + Resource Locators (URL)", RFC 1738, December 1994. + + [7] Bradner, S., "Key Words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [8] The SLAPD and SLURPD Administrators Guide. University of + Michigan, April 1996. + + [9] M. P. Armijo, "Tree Delete Control", Work in Progress. + +Author's Address + + Gordon Good + iPlanet e-commerce Solutions + 150 Network Circle + Mailstop USCA17-201 + Santa Clara, CA 95054, USA + + Phone: +1 408 276 4351 + EMail: ggood@netscape.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Good Standards Track [Page 13] + +RFC 2849 LDAP Data Interchange Format June 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Good Standards Track [Page 14] + diff --git a/ldif.cabal b/ldif.cabal new file mode 100644 --- /dev/null +++ b/ldif.cabal @@ -0,0 +1,53 @@ +Name: ldif +Version: 0.0.1 +License: BSD3 +License-File: LICENSE +Synopsis: The LDAP Data Interchange Format (LDIF) parser +Author: Radoslav Dorcik +Maintainer: radoslav.dorcik@gmail.com +Description: + LDIF files parser implementation using Parsec and based + on RFC 2849 - The LDAP Data Interchange Format (LDIF). + +Category: Text +Stability: experimental +Build-Type: Simple +Cabal-Version: >= 1.6 +Extra-Source-Files: + doc/rfc2253.txt + doc/rfc2849.txt + tests/TestMain.hs + tests/data/OK_simple03.modify.ldif + tests/data/OK_simple01.modify.ldif + tests/data/OK_simple02.content.ldif + tests/data/OK_multivalue.modify.ldif + tests/data/OK_simple01.content.ldif + +Source-Repository head + type: darcs + location: http://rampa.sk/repo/ldif + +flag test + description: Build test program. + default: False + +Library + Build-Depends: ghc, + base < 5, + filepath, + haskell98, + parsec >= 2.1.0, + Cabal >= 1.5 && < 1.7 + Hs-Source-Dirs: src + Extensions: CPP, PatternGuards + Ghc-Options: -Wall -fno-warn-orphans + + Exposed-modules: + Text.LDIF + +Executable test + Hs-Source-Dirs: src, tests + Main-Is: TestMain.hs + Build-Depends: base, HUnit + if !flag(test) + Buildable: False diff --git a/src/Text/LDIF.hs b/src/Text/LDIF.hs new file mode 100644 --- /dev/null +++ b/src/Text/LDIF.hs @@ -0,0 +1,213 @@ +module Text.LDIF ( + parseLDIFStr, + parseLDIFFile, + LDIF(..), + Record(..), + Change(..), + Modify(..), + DN, Attribute, Value, AttrValue +) +where +import Text.ParserCombinators.Parsec +import Data.Either +import Data.Char + +type Attribute = String +type Value = String +type AttrValue = (Attribute, Value) +type DN = String + +-- | Represents LDIF structure, it can be either simply LDIF data dump or +-- | changes LDIF with LDAP operations +data LDIF = LDIFContent { lcVersion :: Maybe String, lcEntries :: [Record] } + | LDIFChanges { lcVersion :: Maybe String, lcEntries :: [Record] } deriving Show + +-- | Represents one record or entry within LDIF file with DN and content +data Record = AttrValRecord { recDN :: DN, recAttrVals :: [AttrValue] } + | ChangeRecord { recDN :: DN, recOp :: Change } deriving Show + +-- | Represents one LDAP operation within changes LDIF +data Change = ChangeAdd { chAttrVals :: [AttrValue] } + | ChangeDelete + | ChangeModify { chMods :: [Modify] } + | ChangeModDN deriving Show + +-- | Represents ChangeModify operations upon one entry within given DN +data Modify = ModAdd { modAttr :: Attribute, modAttrVals :: [AttrValue] } + | ModDelete { modAttr :: Attribute, modAttrVals :: [AttrValue] } + | ModReplace { modAttr :: Attribute, modAttrVals :: [AttrValue] } deriving Show + +-- | Parse string as LDIF content and return LDIF or ParseError +parseLDIFStr :: String -> Either ParseError LDIF +parseLDIFStr = parse pLdif "(param)" + +-- | Read and parse provided file and return LDIF or ParseError +parseLDIFFile :: String -> IO (Either ParseError LDIF) +parseLDIFFile name = do + input <- readFile name + return $ parse pLdif name input + +-- | Parsec ldif parser +pLdif :: CharParser st LDIF +pLdif = try pLdifChanges <|> pLdifContent + +pLdifChanges :: CharParser st LDIF +pLdifChanges = do + ver <- optionMaybe pVersionSpec + recs <- sepEndBy1 pChangeRec pSEPs + return $ LDIFChanges ver recs + +pLdifContent :: CharParser st LDIF +pLdifContent = do + ver <- optionMaybe pVersionSpec + recs <- sepEndBy1 pAttrValRec pSEPs + return $ LDIFContent ver recs + +pAttrValRec :: CharParser st Record +pAttrValRec = do + dn <- pDNSpec + pSEP + attrVals <- sepEndBy1 pAttrValSpec pSEP + return $ AttrValRecord dn attrVals + +pChangeRec :: CharParser st Record +pChangeRec = try pChangeAdd + <|> try pChangeDel + <|> try pChangeMod + <|> pChangeModDN + +pChangeAdd :: CharParser st Record +pChangeAdd = do + dn <- pDNSpec + pSEP + string "changetype:" + pFILL + string "add" + pSEP + vals <- sepEndBy1 pAttrValSpec pSEP + return $ ChangeRecord dn (ChangeAdd vals) + +pChangeDel :: CharParser st Record +pChangeDel = do + dn <- pDNSpec + pSEP + string "changetype:" + pFILL + string "delete" + pSEP + return $ ChangeRecord dn ChangeDelete + +pChangeMod :: CharParser st Record +pChangeMod = do + dn <- pDNSpec + pSEP + string "changetype:" + pFILL + string "modify" + pSEP + mods <- sepEndBy1 pModSpec (char '-' >> pSEP) + return $ ChangeRecord dn (ChangeModify mods) + +pChangeModDN :: CharParser st Record +pChangeModDN = do + dn <- pDNSpec + pSEP + string "changetype:" + pFILL + string "modrdn" + pSEP + string "newrdn:" + pFILL + pRDN + pSEP + string "deleteoldrdn:" + pFILL + oneOf "01" + pSEP + return $ ChangeRecord dn ChangeModDN + +pRDN :: CharParser st String +pRDN = pSafeString + +pDNSpec :: CharParser st DN +pDNSpec = do + string "dn:" + pFILL + pSafeString + +pVersionSpec :: CharParser st String +pVersionSpec = do + string "version:" + pFILL + many1 digit + +pModSpec :: CharParser st Modify +pModSpec = do + modType <- pModType + pFILL + att <- pAttributeDescription + pSEP + vals <- sepEndBy pAttrValSpec pSEP + return $ mkMod modType att vals + +-- TODO: Use something safe instead of error +mkMod :: String -> String -> [AttrValue] -> Modify +mkMod modType att vals | modType == "add:" = ModAdd att vals + | modType == "delete:" = ModDelete att vals + | modType == "replace:" = ModReplace att vals + | otherwise = error $ "unexpected mod:" ++ modType + +pModType :: CharParser st String +pModType = try (string "add:") + <|> try (string "delete:") + <|> string "replace:" + +pAttributeDescription :: CharParser st String +pAttributeDescription = pAttributeType + +pAttributeType :: CharParser st String +pAttributeType = try pLdapOid + <|> (do { l <- letter; o <- pAttrTypeChars; return $ l:o } ) + +pAttrValSpec :: CharParser st AttrValue +pAttrValSpec = do + name <- pAttributeDescription + val <- pValueSpec + return (name, val) + +pValueSpec :: CharParser st Value +pValueSpec = try (char ':' >> char ':' >> pFILL >> pBase64String) + <|> try (char ':' >> pFILL >> pSafeString) + <|> (char ':' >> char '<' >> pFILL >> pURL) + +pURL :: CharParser st String +pURL = pSafeString + +pSafeString :: CharParser st String +pSafeString = do + c <- noneOf "\n\r :<" + r <- many (noneOf "\n\r") + return $ c:r + +pBase64String :: CharParser st String +pBase64String = pSafeString + +pAttrTypeChars :: CharParser st String +pAttrTypeChars = many (satisfy (\x -> isAlphaNum x || x == '-')) + +pLdapOid :: CharParser st String +pLdapOid = do + num <- many1 digit + rest <- many (do { string "."; n <- many1 digit; return $ '.':n}) + return $ num ++ concat rest + +pFILL :: CharParser st () +pFILL = spaces + +pSEP :: CharParser st () +pSEP = try (char '\r' >> char '\n' >> return () ) + <|> (char '\n' >> return () ) + +pSEPs :: CharParser st () +pSEPs = many pSEP >> return () + diff --git a/tests/TestMain.hs b/tests/TestMain.hs new file mode 100644 --- /dev/null +++ b/tests/TestMain.hs @@ -0,0 +1,39 @@ +import Text.LDIF +import Test.HUnit +import Data.Either +import Data.List +import Directory +import System.FilePath +import Control.Monad (liftM) + +ldifDir = "data" + +main = do + ls <- getLDIFs ldifDir + runTestTT (tests ls) + +getLDIFs :: String -> IO [String] +getLDIFs dr = do + liftM (map (dr )) $ liftM (filter isLDIF) $ getDirectoryContents dr + +isOK x = isPrefixOf "OK" (takeFileName x) +isLDIF x = isSuffixOf ".ldif" x + +tests ls = TestList (testCasesParseOK ls) + +testCasesParseOK ls = map (\x -> TestCase (assertParsedOK x)) $ filter (isOK) ls + +assertParsedOK filename = do + ret <- parseLDIFFile filename + either (\e -> assertFailure (show e)) (\ldif -> assertParsedType filename ldif) ret + +assertParsedType name ldif | (isSuffixOf ".modify.ldif" name) = assertTypeChanges name ldif + | (isSuffixOf ".content.ldif" name) = assertTypeContent name ldif + | otherwise = assertFailure $ "Unexpected filename: (not .modify.ldif or .content.ldif " ++ name + +assertTypeContent n l@(LDIFContent _ _) = assertBool "Valid Content Type" True >> (putStrLn $ "\n\n" ++ n ++ "\n\n" ++ (show l)) +assertTypeContent n x = assertFailure $ n ++ " is not type of LDIFContent" + +assertTypeChanges n l@(LDIFChanges _ _) = assertBool "Valid Changes Type" True >> (putStrLn $ "\n\n" ++ n ++ "\n\n" ++ (show l)) +assertTypeChanges n x = assertFailure $ n ++ " is not type of LDIFChanges" + diff --git a/tests/data/OK_multivalue.modify.ldif b/tests/data/OK_multivalue.modify.ldif new file mode 100644 --- /dev/null +++ b/tests/data/OK_multivalue.modify.ldif @@ -0,0 +1,24 @@ +dn: CN=John Smith,OU=Legal,DC=example,DC=com +changetype: modify +replace:employeeID +employeeID: 1234 +- +replace:employeeNumber +employeeNumber: 98722 +- +replace: extensionAttribute6 +extensionAttribute6: JSmith98 +- + +dn: CN=Jane Smith,OU=Accounting,DC=example,DC=com +changetype: modify +replace:employeeID +employeeID: 5678 +- +replace:employeeNumber +employeeNumber: 76543 +- +replace: extensionAttribute6 +extensionAttribute6: JSmith14 +- + diff --git a/tests/data/OK_simple01.content.ldif b/tests/data/OK_simple01.content.ldif new file mode 100644 --- /dev/null +++ b/tests/data/OK_simple01.content.ldif @@ -0,0 +1,3 @@ +dn: cn=The Postmaster,dc=example,dc=com +objectClass: organizationalRole +cn: The Postmaster diff --git a/tests/data/OK_simple01.modify.ldif b/tests/data/OK_simple01.modify.ldif new file mode 100644 --- /dev/null +++ b/tests/data/OK_simple01.modify.ldif @@ -0,0 +1,5 @@ +dn: cn=The Postmaster,dc=example,dc=com +changetype: delete + +dn: cn=somebody,dc=example,dc=com +changetype: delete diff --git a/tests/data/OK_simple02.content.ldif b/tests/data/OK_simple02.content.ldif new file mode 100644 --- /dev/null +++ b/tests/data/OK_simple02.content.ldif @@ -0,0 +1,7 @@ +dn: cn=The Postmaster,dc=example,dc=com +objectClass: organizationalRole +cn: The Postmaster + +dn: cn=somebody,dc=example,dc=com +objectClass: organizationalRole +cn: somebody diff --git a/tests/data/OK_simple03.modify.ldif b/tests/data/OK_simple03.modify.ldif new file mode 100644 --- /dev/null +++ b/tests/data/OK_simple03.modify.ldif @@ -0,0 +1,43 @@ +dn: CN=John Smith,OU=Legal,DC=example,DC=com +changetype: modify +replace:employeeID +employeeID: 1234 +- +replace:employeeNumber +employeeNumber: 98722 +- +replace: extensionAttribute6 +extensionAttribute6: JSmith98 +- + +dn: CN=Jane Smith,OU=Accounting,DC=example,DC=com +changetype: modify +replace:employeeID +employeeID: 5678 +- +replace:employeeNumber +employeeNumber: 76543 +- +replace: extensionAttribute6 +extensionAttribute6: JSmith14 +- + + +dn: CN=Jane Smith,OU=Accounting,DC=example,DC=com +changetype: modify +add:employeeID +employeeID: 5678 +- +delete:employeeNumber +employeeNumber: 76543 +- +replace: extensionAttribute6 +extensionAttribute6: JSmith14 +extensionAttribute6: JSmith18 +- +add: extensionAttribute6 +extensionAttribute6: JSmith14 +extensionAttribute6: JSmith15 +- +delete:employeeNumber +-