Элемент с таким символьным кодом уже существует что значит

Ошибка импорта метаданных.Раздел с таким символьным кодом уже существует.

Новые разделы соответственно не добавляются. Контроль уникальности отключен. Где копать?

12.08.2015 7:11:34—Отправка запроса на авторизацию.
12.08.2015 7:11:34—Отправка запроса на инициализацию, для определения версии обмена данных.
12.08.2015 7:11:35—Процес выполнения обмена: Распаковка архива завершена.
12.08.2015 7:11:35—Процес выполнения обмена: Временные таблицы удалены.
12.08.2015 7:11:35—Процес выполнения обмена: Временные таблицы созданы.
12.08.2015 7:11:35—Процес выполнения обмена: Файл импорта прочитан.
12.08.2015 7:11:36—Процес выполнения обмена: Временные таблицы проиндексированы.
12.08.2015 7:11:36—Процес выполнения обмена: Метаданные импортированы успешно.
12.08.2015 7:11:36—import___2210f587-45e4-4cc0-a0c1-08ce19a9d9f1.xml: Произошла ошибка на стороне сервера.
Ответ сервера:
failure
Ошибка импорта метаданных.Раздел с таким символьным кодом уже существует.
Скрин

та же ошибка, символьные коды везде разные, и в базе и в файле, где он нашел дублирующийся символьный код, на какой группе. Я не понимаю, если вы там в движке видите, что проблема какая-то с символьным кодом, неужели нельзя написать какой символьный код. 4 месяца уже не могу нормально товары выгрузить, каждый новый сайт как новая война, какие-то новые косяки постоянно вылазят, сообщения об ошибках не говорят вообще ни о чем, и народ за это платит по 1000$ и за внедрение еще столько же, жесть.

в персташоп через вебапи выгрузку сделали за 2 недели и работает со всеми сайтами, всеми версиями движка, в маженту аналогично, опенкарт и другие вообще за неделю, а с битриксом чувствую себя идиотом уже, каждому заказчику приходится объяснять что я не дурак и ковыряться в его сайте искать что там на этот раз не так и не нравится битриксу

Источник

Ошибка импорта метаданных.Раздел с таким символьным кодом уже существует.

Новые разделы соответственно не добавляются. Контроль уникальности отключен. Где копать?

12.08.2015 7:11:34—Отправка запроса на авторизацию.
12.08.2015 7:11:34—Отправка запроса на инициализацию, для определения версии обмена данных.
12.08.2015 7:11:35—Процес выполнения обмена: Распаковка архива завершена.
12.08.2015 7:11:35—Процес выполнения обмена: Временные таблицы удалены.
12.08.2015 7:11:35—Процес выполнения обмена: Временные таблицы созданы.
12.08.2015 7:11:35—Процес выполнения обмена: Файл импорта прочитан.
12.08.2015 7:11:36—Процес выполнения обмена: Временные таблицы проиндексированы.
12.08.2015 7:11:36—Процес выполнения обмена: Метаданные импортированы успешно.
12.08.2015 7:11:36—import___2210f587-45e4-4cc0-a0c1-08ce19a9d9f1.xml: Произошла ошибка на стороне сервера.
Ответ сервера:
failure
Ошибка импорта метаданных.Раздел с таким символьным кодом уже существует.
Скрин

та же ошибка, символьные коды везде разные, и в базе и в файле, где он нашел дублирующийся символьный код, на какой группе. Я не понимаю, если вы там в движке видите, что проблема какая-то с символьным кодом, неужели нельзя написать какой символьный код. 4 месяца уже не могу нормально товары выгрузить, каждый новый сайт как новая война, какие-то новые косяки постоянно вылазят, сообщения об ошибках не говорят вообще ни о чем, и народ за это платит по 1000$ и за внедрение еще столько же, жесть.

в персташоп через вебапи выгрузку сделали за 2 недели и работает со всеми сайтами, всеми версиями движка, в маженту аналогично, опенкарт и другие вообще за неделю, а с битриксом чувствую себя идиотом уже, каждому заказчику приходится объяснять что я не дурак и ковыряться в его сайте искать что там на этот раз не так и не нравится битриксу

Источник

Не получается загрузить новые карточки товара в битрикс при помощи «csv»?

Не получается загрузить новые карточки товара
При импорте выдает ошибку
«Ошибки при выполнении операции:
Строка 1. Невозможно создать раздел: Обязательное поле «Символьный код» не заполнено.»
Ошибка у всех загружаемых карточек товара.

При этом такого поля нет в выподающих списках на странице «Импорт данных» во вкладке «поля»

И соответственно нет этих значений при «экспорте» во вкладке «Параметры экспорта»

Где допустил ошибку?
Как исправить?

Экспорт и импорт провожу через «Магазин»
Путь
Рабочий стол-Магазин-Настройки-Экспорт данных (Импорта)

Следует заметить, что импорт CSV, в общем случае, может осуществляться по разному:

При импорте поставить галки «Первая строка содержит имена полей», «Использовать настройки инфоблока для транслитерации символьных кодов». Ну и, естественно, при сохранении файла CSV из Excel необходимо перед загрузкой открыть его, например, в Notepad++, в меню Кодировка преобразовать в UTF-8, сохранить.

Вообще, я для себя сделал табличку соответствия полей.

Источник

Элемент с таким символьным кодом уже существует что значит

Символьные кода нужны для SEO, символьные кода нужны для ЧПУ ведь так /news/ferrari/ лучше чем так /news/48976/. Зачем делать помесь? Гораздо правильнее /news/ferrari-rr/ и /news/ferrari-maranello/ чем
/news/ferrari6419849/ и /news/ferrari4894984/

Помесь как раз в Ваших примерах, что такое rr, cc, qe, az? Никакой логики.

Печально, что вы не сталкивались еще с такими задачами.

Ну, правило для ЧПУ и сейчам можно прописать как /catalog/#ELEMENT_CODE#-#ELEMENT_ID#/

скорее всего, это нужно только для случаев, когда символьные коды совпадают

но тут, пожалуй, нужно или для всех товаров сразу вставлять подстановку ID, или действительно, придумывать уникальные символьные коды, это надежнее и понятнее.

не не, нужно не ЧПУ формировать, а добавлять товары с одним названием, но с разными характеристиками в один инфоблок, а так как у него одно название, то система выдает ошибку и пишет: Елемент с таким символьным кодом уже существует, т.е. не дает сохранить товар.
Данная опция могла бы решить эту проблему и сделать коды уникальными, пока только через события делаю, а так бы галочку в настройках инфоблока Чик и все работает

Эти товары учавствуют в поиске, но в каталоге выводится только один, группируются по названию в один товар, а когда заходим в детальное описание товара (в его карточку), там под ним выводим его характеристики (иначе, предложения товара), и в каждую характеристику есть возможность перейти по ссылке.

Источник

Легкий способ дешифрования закрытой XML-информации

WARNING

bit. ly/qMupEv — оригинальная статья исследователей, обнаруживших уязвимость в XML Encryption.

XML ENCRYPTION

ВЕБ-СЛУЖБЫ

Веб-служба — это метод взаимодействия между двумя электронными устройствами через сеть передачи данных. W3C определяет web-service как программную систему, спроектированную для поддержки интероперабельности machine-to-machine-взаимодействия. Интероперабельность подразумевает открытость интерфейсов и способность взаимодействовать с другими продуктами без каких-либо ограничений доступа и реализации. Зачастую интерфейсы взаимодействия описываются на специальном языке WSDL (Web Services Description Language), в основе которого лежит XML. Веб-сервисы представляют собой наборы инструментов, к наиболее популярным способам использования которых относятся RPC (Remote procedure calls, основная единица взаимодействия — вызов удаленной функции или метода), SOA (Service-oriented architecture, основная единица взаимодействия — сообщение) и REST (Representational state transfer). В последнем случае основными единицами взаимодействия являются операции типа GET, POST, PUT, DELETE и т. д. в протоколах типа HTTP, которые не поддерживают состояния.

МАТЧАСТЬ

Известно, что блочный шифр преобразует блок открытого текста (обычно длиной 16 байт, то есть 128 бит) в блок шифрованного текста. Если данные занимают больше одного блока, приходится использовать алгоритмы, самым популярным из которых на сегодня является CBC. Принцип его работы легко понять из первой иллюстрации. Для первого блока открытого текста случайно выбирается вектор инициализации (IV), а затем над этим вектором и первым блоком открытого текста выполняется операция XOR, результат которой шифруется с помощью блочного алгоритма. В качестве вектора инициализации для последующих блоков открытого текста используется предыдущий блок шифрованного текста, то есть весь процесс шифрования и дешифрования описывается следующим псевдокодом:

Здесь k — ключ, С — шифротекст, М — открытый текст, IV — вектор инициализации (синхропосылка).

Стандарт не только предписывает использовать режим шифрования CBC, но и определяет схему дополнения данных до полного блока.

Режим CBC (шифрование и дешифрование)

Хакер #156. Взлом XML Encryption

Суть этой схемы, в которой также нет ничего сложного, такова: неполный блок с помощью произвольных значений дополняется до полного, а в его последний байт вписывается количество этих произвольных значений. Так, если последний блок содержит всего три байта, то мы добавляем 12 произвольных байт и один байт со значением 0x05. Если же последний блок полон (содержит 16 байт), то мы цепляем к нему еще один блок, 15 байт которого задаются произвольно, а 16-й имеет значение 0x10.

ОСНОВНАЯ ИДЕЯ АТАКИ

Прежде чем переходить к рассмотрению практических случаев, я опишу основную идею атаки на XML Encryption. Как ты уже догадался, ее не просто так ставят в один ряд с BEAST и Padding Oracle Attack. В данном случае атака также строится на передаче атакуемому серверу специально сформированных запросов и анализе получаемых сообщений об ошибках. Перейдем к делу. Основной недостаток режима шифрования CBC состоит в том, что изменение шифрованного текста влияет на открытый текст, то есть если применить XOR к вектору инициализации IV и произвольной битовой маске MSK, то шифротекст (IV xor MSK, C[0]) будет соответствовать сообщению M[0] xor MSK. Как видишь, зависимость в данном случае очень проста.

Чтобы осуществить предлагаемую атаку, нужно изменить шифрованный текст с помощью маски MSK, передать измененное сообщение на удаленный сервер и проанализировать сообщение об ошибке, которое позволяет узнать дополнительную информацию об открытом тексте. Таким образом, получается этакий побочный канал для получения конфиденциальной информации.

Для начала давай разберемся с простеньким примером атаки, который показывает, как получить открытый текст зашифрованного сообщения. Атака на XML Encryption основана именно на этой идее, которая слегка адаптирована к «реальному миру».

Упрощенный вариант атаки

Будем считать, что информация, которую мы передаем, кодируется в ASCII. Разобьем всю таблицу ASCII на две части. В первую часть войдут все символы, кроме NULL (список А), а во вторую — все остальные символы (список B). Шифрованный текст, полученный из открытого текста, символы которого находятся в списке B, будем считать «правильно сформированным». Таким образом, если шифротекст сформирован правильно, то наш сервер при парсинге открытого сообщения не будет выдавать ошибок. Условимся также, что наши сообщения состоят всего лишь из одного блока открытого текста, то есть из 16 байт, а удаленный сервер в ответ на наши запросы возвращает true, если открытый текст M[0] = AESDECCBC(k, (IV, C[0])) не содержит запретного символа NULL, и false — в противном случае.

Теперь, посылая запросы нашему серверу, можно побайтно восстанавливать сообщения. Алгоритм восстановления состоит всего из трех этапов:

Вот что имеется у нас на входе и выходе:

В алгоритме нет ничего сложного. Изменяя j-й байт вектора инициализации, мы наблюдаем за сообщениями сервера и ждем, пока на j-м месте в открытом тексте появится наш запретный символ. Ты спросишь меня, почему так? Отвечу: таков режим CBC. Для него справедливо следующее (опять все внимание на первую иллюстрацию):

XML И XML ENCRYPTION

Extensible Markup Language (или коротко XML) представляет собой язык разметки для сериализации древовидных структур. Важная особенность XML состоит в том, что символы « » разрешается использовать только для обозначения узловых элементов (node). Так, если текст содержит один из этих символов, то перед сериализацией в XML его необходимо заменить на « » соответственно. Точно так же для символа апмерсанда «&» применяется escape-последовательность «&». Перечисленные свойства XML играют важную роль при атаке на XML Encryption.

Синтаксис XML Encryption

Консорциум W3C выпустил рекомендации XML Signature и W3C XML Encryption, что способствовало стандартизации XML и средств для применения криптографических примитивов (электронной цифровой подписи, симметричных алгоритмов и т. д.) к произвольным данным в формате XML.

XML SIGNATURE

XML Signature — спецификация W3C, определяющая синтаксис и порядок применения электронной цифровой подписи и кодов аутентификации для данных в формате XML.

Так как технологию XML Encryption можно применять к произвольной части дерева XML-документа (лишь бы она имела корректный синтаксис XML), то для разных типов контента существуют разные режимы шифрования. Используемый режим указывается в поле Type тега. Тип Encrypted Element означает, что дешифрованию подвергается один XML-элемент со всеми своими дочерними узлами. Тип Encrypted Content говорит о том, что дешифрованию подвергается произвольное количество узловых элементов со всеми своими дочерними элементами, комментариями, инструкциями по обработке и т. д. Тип Encrypted Text Content, являющийся частным случаем типа Encrypted Content, выделен для таких открытых текстов, которые состоят только из текстовых данных. Таким образом, информация в поле Type дает нам подсказку об открытом тексте. Стоит отметить, что при дешифровании этот атрибут обычно игнорируется XML Framework’ом и не влияет на последовательность действий при обработке шифрованного текста.

Пару слов необходимо сказать и еще об одном важном моменте — кодировке. Стандарт XML Encryption предписывает использовать кодировку UTF-8, которая указывает битовое представление символов различных алфавитов, а также других специальных символов. Наиболее значимая для нас группа символов всей таблицы UTF-8 — это символы английского алфавита, цифры, а также спецсимволы перевода строки (line feed) и возврата каретки (carriage return). Важно знать, что для этой группы символов коды ASCII совпадают с кодами UTF-8.

Также ты наверняка помнишь, что код ASCII представляет символы как одиночные байты и позволяет закодировать 128 различных символов (смотри рисунок 4). Замечу, что эта кодировка использует только семь из восьми бит в байте, старший бит всегда равен нулю.

AXIS2 — ФРЕЙМВОРК ДЛЯ СОЗДАНИЯ ВЕБ-СЕРВИСОВ

За последние несколько лет появилось довольно много фреймворков для разработки веб-сервисов. Одним из самых популярных решений в этой области является Apache Axis2 Framework, модуль Rampart которого содержит реализацию стандарта WS-Security. Этот стандарт и позволяет нам применять XML Encryption и XML Signature в сообщениях SOAP.

WS-SECURITY

WS-Security — гибкое и многофункциональное расширение SOAP, служащее для организации безопасного взаимодействия в веб-сервисах. WS-Security активно использует XML Encryption и XML Signature.

Чтобы этот модуль можно было использовать в Axis2 Framework, он должен быть элементом потока обработки сообщений (message flow). Поток обработки сообщений (message flow) — это цепочка модулей, каждый из которых получает входящее SOAP-сообщение (или контекст сообщения), обрабатывает его и передает следующему модулю в цепочке. Когда SOAP-сообщение достигает конца цепочки, оно перенаправляется в Message Receiver, который, в свою очередь, вызывает функцию класса Service и отправляет результат пользователю сервиса.

Message flow в Apache Axis2

Обычно поток обработки сообщений в Axis2 состоит из трех модулей: Transport, Security и Dispatch. Модуль Security, как видно из названия, отвечает за безопасность. В процессе обработки зашифрованного сообщения он сначала осуществляет процесс дешифрования, а затем парсит открытый текст с помощью парсера XML и обновляет контекст SOAP-сообщения. Дешифрованный и проверенный контент передается модулю Dispatch. Как и Message Receiver, каждый модуль в цепочке message flow может прервать процесс обработки сообщения SOAP при возникновении ошибки, после чего процесс обработки прекращается и пользователю сервиса выдается соответствующее сообщение.

ОШИБКИ В СИСТЕМЕ БЕЗОПАСНОСТИ В AXIS2

ЧТО ТАКОЕ ОРАКУЛЫ?

В качестве оракула у нас будет выступать сервер с веб-сервисом, созданным с использованием Axis2. Поначалу нам нужно понять, какие сообщения об ошибках безопасности выдает сервер, так как тогда мы сможем отличить ответ true от ответа false нашего оракула. При возникновении ошибки безопасности сервис передает нам security fault. Причины генерации security fault можно разделить на две категории: 1. Ошибка дешифрования Такая ошибка возникает при некорректном дополнении последнего блока. Помнишь, я говорил, что последний байт каждого сообщения содержит число, равное количеству дополненных байтов? Так вот, этот последний байт может принимать значения от 0x01 до 0x10, в противном случае мы получаем сообщение об ошибке. 2. Ошибка парсинга данных Эта ошибка может возникнуть по двум причинам. Первая — открытый текст содержит «запрещенные» символы, то есть символы с кодами ASCII от 0x00 до 0x1F (за исключением 0x09, 0x0A, 0x0D — пробела, конца строки и возврата каретки). Вторая причина — некорректный XML-синтаксис дешифрованного сообщения, что означает появление в открытом тексте символа «&» (0x26) или « ».

В обоих случаях мы получаем одинаковое сообщение об ошибке и различить эти два случая между собой лишь по сообщению не можем.

Как и в приведенном ранее простом примере, разобьем всю нашу таблицу ASCII на две группы символов (все внимание на четвертый рисунок). Группа A содержит запрещенные для формата XML символы плюс два «зарезервированных» символа «&» и «

Таблица ASCII с делением символов на группы

Теперь все готово для построения оракула. Как и в примере, наш оракул, то есть сервер, получает на вход один блок текста, зашифрованного в режиме CBC, то есть 16-байтовый вектор инициализации и зашифрованный блок такого же размера, и возвращает true или false. Конечно, этот блок должен быть правильно «обернут» в SOAP-сообщение, но здесь мы этим пренебрегаем. Итак, оракул возвращает true, если сервер в ответ на SOAP(AESENCCBC(k, (IV, C))) передает нам security fault, и возвращает false в противном случае.

Как я уже говорил, сервер не выдаст security fault, если на стороне сервера сообщение имеет правильное дополнение до полного блока, то есть открытый текст M имеет верную XML-структуру:

В противном случае возникает ошибка security fault, что позволяет нам использовать оракул точно так же, как и в предыдущем более простом примере.

ВОССТАНОВЛЕНИЕ ОТКРЫТОГО ТЕКСТА

Для простоты считаем, что открытый текст состоит только из символов ASCII (то есть в тексте нет ни одного символа из расширенной секции UTF-8). В отличие от случая, описанного в простом примере, здесь «правильно сформированным» шифротекстом является такой шифротекст, открытый текст которого состоит из символов группы B и имеет однобайтное дополнение, то есть последний его байт равен 0x01 (это допущение введено для более простого изложения идеи атаки).

Алгоритм прост и не нуждается в подробном разъяснении. Скажу лишь только, что получить открытый текст M таким способом возможно благодаря режиму CBC (смотри на картинку, и все станет ясно). Остается только рассказать тебе об устройстве двух загадочных функций: FindIV и FindXbyte.

ПРОЦЕДУРЫ FINDIV И FINDXBYTE

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

Источник