ldif (empty) → 0.0.1
raw patch · 12 files changed
+1766/−0 lines, 12 filesdep +Cabaldep +HUnitdep +basesetup-changed
Dependencies added: Cabal, HUnit, base, filepath, ghc, haskell98, parsec
Files
- LICENSE +27/−0
- Setup.hs +2/−0
- doc/rfc2253.txt +563/−0
- doc/rfc2849.txt +787/−0
- ldif.cabal +53/−0
- src/Text/LDIF.hs +213/−0
- tests/TestMain.hs +39/−0
- tests/data/OK_multivalue.modify.ldif +24/−0
- tests/data/OK_simple01.content.ldif +3/−0
- tests/data/OK_simple01.modify.ldif +5/−0
- tests/data/OK_simple02.content.ldif +7/−0
- tests/data/OK_simple03.modify.ldif +43/−0
+ LICENSE view
@@ -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.
+ Setup.hs view
@@ -0,0 +1,2 @@+import Distribution.Simple+main = defaultMain
+ doc/rfc2253.txt view
@@ -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 = <any character except "\" or QUOTATION >++special = "," / "=" / "+" / "<" / ">" / "#" / ";"++pair = "\" ( special / "\" / QUOTATION / hexpair )+stringchar = <any character except one of special, "\" or QUOTATION >++hexstring = 1*hexpair+hexpair = hexchar hexchar++hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"+ / "a" / "b" / "c" / "d" / "e" / "f"++ALPHA = <any ASCII alphabetic character>+ ; (decimal 65-90 and 97-122)+DIGIT = <any ASCII decimal digit> ; (decimal 48-57)+QUOTATION = <the ASCII double quotation mark character '"' decimal 34>+++++++++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]+
+ doc/rfc2849.txt view
@@ -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+ ; <name-component> 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 = <a Uniform Resource Locator,+ as defined in [6]>+ ; (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=<JapaneseOU>,o=Airius+objectclass: top+objectclass: organizationalUnit+ou:: 5Za25qWt6YOo+# ou:: <JapaneseOU>+ou;lang-ja:: 5Za25qWt6YOo+# ou;lang-ja:: <JapaneseOU>+ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2++++Good Standards Track [Page 8]++RFC 2849 LDAP Data Interchange Format June 2000+++# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>+ou;lang-en: Sales+description: Japanese office++dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz+# dn:: uid=<uid>,ou=<JapaneseOU>,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:: <JapaneseGivenname>+sn;lang-ja:: 5bCP56yg5Y6f+# sn;lang-ja:: <JapaneseSn>+cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==+# cn;lang-ja:: <JapaneseCn>+title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==+# title;lang-ja:: <JapaneseTitle>+preferredlanguage: ja+givenname:: 44Ot44OJ44OL44O8+# givenname:: <JapaneseGivenname>+sn:: 5bCP56yg5Y6f+# sn:: <JapaneseSn>+cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==+# cn:: <JapaneseCn>+title:: 5Za25qWt6YOoIOmDqOmVtw==+# title:: <JapaneseTitle>+givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8+# givenname;lang-ja;phonetic::+<JapaneseGivenname_in_phonetic_representation_kana>+sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ+# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>+cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==+# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>+title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==+# title;lang-ja;phonetic::+# <JapaneseTitle_in_phonetic_representation_kana>+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. <URL:+ http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>++ [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]+
+ ldif.cabal view
@@ -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 <radoslav.dorcik@gmail.com>+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
+ src/Text/LDIF.hs view
@@ -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 ()+
+ tests/TestMain.hs view
@@ -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"+
+ tests/data/OK_multivalue.modify.ldif view
@@ -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+-+
+ tests/data/OK_simple01.content.ldif view
@@ -0,0 +1,3 @@+dn: cn=The Postmaster,dc=example,dc=com+objectClass: organizationalRole+cn: The Postmaster
+ tests/data/OK_simple01.modify.ldif view
@@ -0,0 +1,5 @@+dn: cn=The Postmaster,dc=example,dc=com+changetype: delete++dn: cn=somebody,dc=example,dc=com+changetype: delete
+ tests/data/OK_simple02.content.ldif view
@@ -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
+ tests/data/OK_simple03.modify.ldif view
@@ -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+-