Московский государственный университет имени М.В.Ломоносова
Опубликован: 26.01.2005 | Доступ: свободный | Студентов: 4903 / 1264 | Оценка: 4.17 / 3.92 | Длительность: 21:54:00
ISBN: 978-5-9556-0020-8
Лекция 3:

Инфраструктура Открытого Ключа (часть 3)

< Лекция 2 || Лекция 3: 12345 || Лекция 4 >
Операция Modify

Операция Modify позволяет клиенту запросить модификацию записи на сервере. Запрос Modify определяется следующим образом:

ModifyRequest ::= [APPLICATION 6] SEQUENCE {
  object       LDAPDN, 
  modification SEQUENCE OF SEQUENCE { 
    operation ENUMERATED { 
      add     (0), 
      delete  (1), 
      replace (2) }, 
    modification AttributeTypeAndValues } 
} 
AttributeTypeAndValues ::= SEQUENCE { 
  type AttributeDescription, 
  vals SET OF AttributeValue 
}

Перечислим параметры запроса Modify :

  • Object: модифицируемый объект. Значение данного поля содержит DN модифицируемой записи. Сервер не рассматривает никаких alias для определения модифицируемой записи.
  • Modification: список модификаций, выполняемых для записи. Весь список модификаций записи должен быть выполнен в том порядке, в котором он перечислен, как одна атомарная операция. Хотя отдельные модификации могут нарушать схему Каталога, результирующая запись, после того как весь список модификаций выполнен, должна соответствовать требованиям схемы Каталога. Значения, которые могут находиться в поле "operation" для каждой модификации, имеют следующую семантику:
    • Add : добавление перечисленных значений для данного атрибута; при необходимости атрибут создается.
    • Delete : удаление перечисленных значений для данного атрибута; весь атрибут удаляется, если никаких значений не указано или все текущие значения атрибута перечислены для удаления.
    • Replace: замена всех существующих значений данного атрибута новыми перечисленными значениями; если атрибута не существует, он создается. Замена без указания значения удаляет весь атрибут, если он есть, и игнорируется, если атрибута не существует.

Результат модификации, которую пытался выполнить сервер при получении ModifyRequest, возвращается в ModifyResponse, который определяется следующим образом:

ModifyResponse ::= [APPLICATION 7] LDAPResult

При получении ModifyRequest сервер выполняет необходимые модификации в DIT.

Сервер возвращает клиенту единственный ModifyResponse, указывающий либо на успешное завершение модификации DIT, либо на причину неудачного завершения. Заметим, что при требовании атомарности применения списка модификаций в ModifyRequest клиент может считать, что ни одна модификация DIT не выполнена, если полученный ModifyResponse указывает на какую-либо ошибку, и что все запрошенные модификации прошли удачно, если ModifyResponse указывает на успешное завершение операции модификации.

Операция Modify не может быть использована для удаления из записи любого полного уникального имени и тех значений, которые формируют относительное уникальное имя записи. Попытка сделать это приведет к тому, что сервер вернет ошибку notAllowedOnRDN. Для переименования записи используется операция ModifyDN , которая будет описана ниже.

Операция Add

Операция Add позволяет клиенту запросить добавление записи в Каталог. AddRequest определяется следующим образом:

AddRequest ::= [APPLICATION 8] SEQUENCE {
    entry      LDAPDN, 
    attributes AttributeList 
} 
AttributeList ::= SEQUENCE OF SEQUENCE { 
    type AttributeDescription, 
    vals SET OF AttributeValue 
}

Параметрами AddRequest являются:

  • Entry: полное уникальное имя добавляемой записи. Заметим, что сервер не определяет никаких aliases при размещении добавляемой записи.
  • Attributes: список атрибутов, которые определяют содержание добавляемой записи. Клиенты должны включать в этот список полные значения (которые формируют собственный RDN записи), атрибут objectClass и значения всех обязательных атрибутов перечисленных классов объектов. Клиенты не должны указывать NO-USER-MODIFICATION атрибуты, такие как createTimestamp или creatorName атрибуты, так как сервер поддерживает их автоматически.

Запись, указанная в поле AddRequest, существовать не должна. Непосредственный родитель добавляемых записей объекта должен существовать. Например, если клиент пытается добавить CN=JS, DC=Example, DC=NET, а запись DC=Example, DC=NET не существует и запись DC=NET существует, то сервер вернет ошибку noSuchObject с полем matchedDN, содержащим DC=NET. Если родительская запись существует, но не находится в контексте именования, поддерживаемом сервером, сервер должен возвратить ссылку на сервер, содержащий родительскую запись.

При получении AddRequest сервер пытается добавить запрошенную запись. Результат попытки добавления будет возвращен клиенту в AddResponse, определенном следующим образом:

AddResponse ::= [APPLICATION 9] LDAPResult

Успешный ответ указывает на то, что новая запись добавлена в Каталог.

Операция Delete

Операция Delete позволяет клиенту запросить удаление записи из директории. DeleteRequest определяется следующим образом:

DelRequest ::= [APPLICATION 10] LDAPDN

DeleteRequest состоит из Distinguished Name удаляемой записи. Заметим, что сервер по aliases не переходит и что только концевые записи (которые не имеют подчиненных записей) могут быть удалены с помощью данной операции.

Результат операции удаления, выполненной сервером при получении DeleteRequest, возвращается в DeleteResponse, определяемом следующим образом:

DelResponse ::= [APPLICATION 11] LDAPResult

При получении DeleteRequest сервер пытается выполнить удаление указанной записи. Результат возвращается клиенту в DeleteResponse.

< Лекция 2 || Лекция 3: 12345 || Лекция 4 >
Илья Сидоркин
Илья Сидоркин

Добрый день! Подскажите пожалуйста как и когда получить диплом, после сдичи и оплаты?????

Наталья Шульга
Наталья Шульга

Курс "информационная безопасность" .

Можно ли на него записаться на ПЕРЕПОДГОТОВКУ по данному курсу? Выдается ли диплом в бумажном варианте и высылается ли он по почте?