From Fedora Project Wiki

Revision as of 01:28, 5 September 2012 by Jdennis (talk | contribs) (Created page with "{{QA/Test_Case |description= IPA utilizes LDAP to store most of it's data. In most cases the name you give an object in IPA will be included in an LDAP Distinguished Name (DN...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Description

IPA utilizes LDAP to store most of it's data. In most cases the name you give an object in IPA will be included in an LDAP Distinguished Name (DN). DN's have specific rules governing how to express a DN when it contains reserved characters. Earlier versions of IPA were not rigorous when manipulating user provided names which would have allowed invalid DN's to be constructed internally leading to internal errors. IPA version 3 has significantly enhanced how DN's are constructed and manipulated with an eye to avoiding problems caused by user supplied names. In this test case we would like you to select names which in the past would have been problematic for IPA and verify there are no operational problems as a result of these names.

Examples of items represented as DN's

  1. IPA realm
  2. User names
  3. Group names
  4. Host names
  5. HBAC rule names
  6. SUDO rule names

Problematic names ordered by testing need

  1. Name ends with a comma (e.g. "Bob,")
  2. Name begins with an equal sign (e.g. "=Bob")
  3. Name contains plus sign (e.g. "Bob+Joe")
  4. Name utilizes non-ASCII characters (see international names below)
  5. Name ends with a backslash (e.g. "Bob\").
  6. Name contains any of the reserved DN characters (see below)

Case should not matter

Names are supposed to be case insenstive. If you define a name with one set of case (e.g. "Bob") you should still be able to operate on that name using a different case (e.g. "BOB").

UTF-8 Unicode (international) names should be supported.

This is of particular interest to non-English speaking users who desire to use names in their native language utilizing characters (code points) from their language character set. Examples would be names in Japanese, Arabic or Russian. IPA uses the UTF-8 Unicode encoding scheme. Thus any name which is valid UTF-8 should work. The following web site provides examples of internationalized names using non-ASCII characters http://www.i18nguy.com/unicode-example.html You can cut-n-paste names from that page for testing because the page is encoded in UTF-8.

Reserved DN characters

The following characters are reserved in DN syntax and IPA must properly escape them:

  1. ’"’ (unicode U+0022)
  2. ’+’ (unicode U+002B)
  3. ’,’ (unicode U+002C)
  4. ’;’ (unicode U+003B)
  5. ’<’ (unicode U+003C)
  6. ’>’ (unicode U+003E)
  7. ’\’ (unicode U+005C)


How to test

Performing these tests requires an understanding of IPA. It is not pratical to list every step of every operation. If you already know how to use both the web interface and the command interface then in essence what we're asking you to do is to create and manipulate a variety of IPA objects using some of the problematic names identified above and verify no errors are reported and the actions and results are the same as with non-problematic names. Because we're not giving you exact instructions you're more likely to exercise the system in ways we don't anticipate (if we gave you exact steps to follow you might just end repeating what our unit tests already cover).


Perform an install as described here QA:Testcase_freeipav3_installation but use one of the problematic names defined above for the realm name. A particularly pernicious realm name would be one beginning with a comma (',') or equal sign ('=') because the realm is used as a DN suffix.

Then using either the IPA instance just created or another do the following

Create users, groups, hosts and rules with any of the problematic names. Assure you can search and filter with those names and they appear in all expected output and that case sensitivity is not a factor. These problematic names should work equally well using either the web interface or the command line interface (i.e. CLI). Testers should perform the same action in both the web UI and with the cli because portions of the operation pass through different code paths.

Expected Results

  • No errors reported
  • Names show up as expected
  • Both the web interface and the cli interface produce the same result.