Сообщение не принято ветис текст ошибки код состояния http 500

Добрый всем.
Подскажите, кто уже знает.
Настраиваю новое подключение в Ветис. УТ 11.4.13.280 на платформе 8.3.20.1549, практически ещё новая, немодифицированная база. Галки на тестовом контуре нет.
Создаю новое подключение.

Нажимаю далее, сразу получаю отказ:

Служба поддержки Ветис сообщает, что
«Реквизиты доступа корректны.
С ними удалось успешно подключиться к точке доступа https://api.vetrf.ru/platform/services/2.0/ApplicationManagementService.»

Значит, что-то в УТ? Что может быть в стандартном УТ, на котором я не первый, и, подозреваю, не стотысячный?

Любопытно, что при формировании настроек подключения, в графе пароль дублируется Ключ API

Но при подстановке туда реального пароля результат меняется незначительно:
«Сообщение не принято ВетИС: Текст ошибки: Код состояния HTTP: 401. Описание ошибки: Нет доступа.»

При дальнейшей трассировке, выяснил, сто УТ обращается не к
platform/services/2.0/ApplicationManagementService, как сообщают в поддержке, а к
platform/services/2.1/EnterpriseService

Полный текст ошибки, возвращаемый Ветисом:
«The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.46) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity MAY include relevant diagnostic information. HTTP access authentication is explained in section 11.»

В общем, упёрся. Приветствую любые мысли. Спасибо.

Появление сообщения об ошибке 401 Unauthorized Error («отказ в доступе») при открытии страницы сайта означает неверную авторизацию или аутентификацию пользователя на стороне сервера при обращении к определенному url-адресу. Чаще всего она возникает при ошибочном вводе имени и/или пароля посетителем ресурса при входе в свой аккаунт. Другой причиной являются неправильные настройки, допущенные при администрировании web-ресурса. Данная ошибка отображается в браузере в виде отдельной страницы с соответствующим описанием. Некоторые разработчики интернет-ресурсов, в особенности крупных порталов, вводят собственную дополнительную кодировку данного сбоя:

Попробуем разобраться с наиболее распространенными причинами возникновения данной ошибки кода HTTP-соединения и обсудим способы их решения.

При доступе к некоторым сайтам (или отдельным страницам этих сайтов), посетитель должен пройти определенные этапы получения прав:

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

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

Некоторые крупные интернет-ресурсы с большим количеством подписчиков используют дополнительные настройки для обеспечения безопасности доступа. К примеру, ваш аккаунт может быть заблокирован при многократных попытках неудачной авторизации. Слишком частые попытки законнектиться могут быть восприняты как действия бота. В этом случае вы увидите соответствующее сообщение, но можете быть просто переадресованы на страницу с кодом 401. Свяжитесь с администратором сайта и решите проблему.

Иногда простая перезагрузка проблемной страницы, выход из текущей сессии или использование другого веб-браузера полностью решают проблему с 401 ошибкой авторизации.

Устранение ошибки 401 администратором веб-ресурса

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

Где в поле /oldpage. html прописывается адрес проблемной страницы, а в https://site. com/newpage. html адрес страницы авторизации.

Таким образом вы перенаправите пользователей со всех страниц, которые выдают ошибку 401, на страницу начальной авторизации.

Хотя ошибка 401 и является проблемой на стороне клиента, ошибка пользователя на стороне сервера может привести к ложному требованию входа в систему. К примеру, сетевой администратор разрешит аутентификацию входа в систему всем пользователям, даже если это не требуется. В таком случае сообщение о несанкционированном доступе будет отображаться для всех, кто посещает сайт. Баг устраняется внесением соответствующих изменений в настройки.

Дополнительная информация об ошибке с кодом 401

Веб-серверы под управлением Microsoft IIS могут предоставить дополнительные данные об ошибке 401 Unauthorized в виде второго ряда цифр:

Более подробную информацию об ошибке сервера 401 при использовании обычной проверки подлинности для подключения к веб-узлу, который размещен в службе MS IIS, смотрите здесь.

Следующие сообщения также являются ошибками на стороне клиента и относятся к 401 ошибке:

Как видим, появление ошибки авторизации 401 Unauthorized не является критичным для рядового посетителя сайта и чаще всего устраняется самыми простыми способами. В более сложной ситуации оказываются администраторы и владельцы интернет-ресурсов, но и они в 100% случаев разберутся с данным багом путем изменения настроек или корректировки html-кода с привлечением разработчика сайта.

Что такое несанкционированная ошибка 401 и как ее исправить (объяснение 4 решений)

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

Но что именно эти коды ошибок появляются из ниоткуда и не объясняют, почему они появились в первую очередь?

Проще говоря, Интернет или Всемирная паутина функционируют на основе прикладного протокола, предназначенного для распределенных и совместных гипермедиа информационных систем, иначе называемых HTTP или протокол передачи гипертекста.

Другими словами, HTTP обеспечивает связь между клиентами и серверами, что позволяет беспрепятственно передавать данные между ними.

Типы ошибок 4xx

Ошибки или коды состояния, начинающиеся с цифры 4, часто относятся к ошибкам клиента. Другими словами, проблемы имеют отношение к клиентским запросам или напрямую связаны с клиентами.

Более того, эти ошибки могут указывать на временную или постоянную ситуацию. Вот несколько примеров 400 кодов ошибок.

Теперь, когда мы лучше понимаем эти надоедливые коды ошибок, пришло время сосредоточиться на 401 и как избавиться от него.

Исправление кода ошибки 401: точка зрения пользователя

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

Тем не менее, что происходит, когда вы фактически предоставляете правильные учетные данные для входа, но сервер по-прежнему предоставляет вам неавторизованное сообщение?

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

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

1. Проверьте URL

2. Проверьте свои учетные данные

3. Очистить историю просмотров и куки

4. Флеш DNS

Исправление ошибки 401: взгляд веб-мастера

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

Откат к предыдущей версии

Влияние ошибок на пользователей

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

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

But where’s the fun in that? Indeed, a dull message describing a solution to the error may be off-putting, to say the least. That’s why developers oftentimes go a step further to ease the users’ pain.

В любом случае, даже неудобство может стать возможностью изменить ситуацию и превратить разочарование пользователей в не слишком большое разочарование.

Заключение

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

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

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

Вот почему важно понимать, как подойти к проблеме, а также понять, как правильно ее решить.

Реквизиты для авторизации

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

• login — логин для авторизации в security-слое.
• password — пароль для авторизации в security-слое.

Для того, чтобы получить доступ к шлюзу, необходимо пройти авторизацию в security-слое (HTTP-авторизацию) с использованием логина и пароля. Пара логин-пароль выдается одна на информационную систему.

• APIKey — уникальный ключ, однозначно идентифицирующий информационную систему в шлюзе. Выдаётся один на одну информационную систему.
• issuerID — уникальный идентификатор хозяйствующего субъекта или ветеринарного управления, работающего через указанную информационную систему. Является уникальным идентификатором организации (хозяйствующего субъекта или ветеринарного управления) в реестре РСХН.

Через одну информационную систему может работать несколько организаций и тогда им будет выдан один APIKey и множество IssuerID. Связка APIKey — IssuerID идентифицирует подключающегося к шлюзу хозяйствующего субъекта или ветеринарное управление. Эта авторизация происходит непосредственно в шлюзе и обеспечивает доступ к приложениям.

Сценарий подключения к шлюзу

При подключении к шлюзу пользователь проходит трех этапную авторизацию. Процесс авторизации изображён на рис. 1.

• Первый этап — авторизация в security-слое с использованием логина и пароля, указанных в письме в разделе с APIKey и issuerId. Это HTTP-авторизация и в случае, если она не пройдена, доступ к шлюзу не будет открыт.
• Второй этап — авторизация непосредственно в самом шлюзе с использованием APIKey и IssuerID. В ходе этого процесса происходит удостоверение в подлинности информационной системы и хозяйствующего субъекта, который через неё работает.
• Третий этап — авторизация в приложении (сервисе) с использованием логина пользователя, зарегистрированного в ВетИС. Это должен быть либо логин ветеринарного врача, либо, для некоторых операций (не выписки ВСД), логин пользователя ХС. По сути, это уже не работа со шлюзом, а работа с приложением через шлюз. Хозяйствующий субъект может получить реквизиты доступа к системе, обратившись в Территориальное управление Россельхознадзора. Логин идентифицирует пользователя, который производит операции в приложении. Кроме того, именно от имени этого пользователя будут выданы ветеринарные сертификаты.

Список типичных ошибок при авторизации

Ошибка и сообщение	Причина
401 Unauthorized. The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.46) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization failed.	Пользователь шлюза не прошёл первичную авторизацию в security-слое. Причины могут быть следующие: Не указаны логин и пароль, требуемые для авторизации. Они приходят в письме вместе с apiKey и IssuerID. Логин и/или пароль указаны неверно. Необходимо проверить правильность идентифкационных данных.
Указан некорректный ключ доступа к интеграционному шлюзу.	Неверно указан apiKey. Необходимо проверить, насколько правильно его скопировали из письма.
Доступ запрещен для комбинации указанных ключа доступ и идентификатора заявителя.	Неверно указан issuerID. Необходимо проверить правильность указанного issuerID.
Ошибка авторизации в приложении.	Пользователь с указанным логином не найден в списке пользователей.

Появление сообщения об ошибке 401 Unauthorized Error («отказ в доступе») при открытии страницы сайта означает неверную авторизацию или аутентификацию пользователя на стороне сервера при обращении к определенному url-адресу. Чаще всего она возникает при ошибочном вводе имени и/или пароля посетителем ресурса при входе в свой аккаунт. Другой причиной являются неправильные настройки, допущенные при администрировании web-ресурса. Данная ошибка отображается в браузере в виде отдельной страницы с соответствующим описанием. Некоторые разработчики интернет-ресурсов, в особенности крупных порталов, вводят собственную дополнительную кодировку данного сбоя:

• 401 Unauthorized;
• Authorization Required;
• HTTP Error 401 – Ошибка авторизации.

Попробуем разобраться с наиболее распространенными причинами возникновения данной ошибки кода HTTP-соединения и обсудим способы их решения.

Причины появления ошибки сервера 401 и способы ее устранения на стороне пользователя

При доступе к некоторым сайтам (или отдельным страницам этих сайтов), посетитель должен пройти определенные этапы получения прав:

1. Идентификация – получение вашей учетной записи («identity») по username/login или email.
2. Аутентификация («authentic») – проверка того, что вы знаете пароль от этой учетной записи.
3. Авторизация – проверка вашей роли (статуса) в системе и решение о предоставлении доступа к запрошенной странице или ресурсу на определенных условиях.

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

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

1. Проверьте в адресной строке правильность написания URL. Особенно это касается перехода на подстраницы сайта, требующие авторизации. Введите правильный адрес. Если переход на страницу осуществлялся после входа в аккаунт, разлогинитесь, вернитесь на главную страницу и произведите повторный вход с правильными учетными данными.
2. При осуществлении входа с сохраненными данными пользователя и появлении ошибки сервера 401 проверьте их корректность в соответствующих настройках данного браузера. Возможно, авторизационные данные были вами изменены в другом браузере. Также можно очистить кэш, удалить cookies и повторить попытку входа. При удалении истории браузера или очистке кэша потребуется ручное введение логина и пароля для получения доступа. Если вы не помните пароль, пройдите процедуру восстановления, следуя инструкциям.
3. Если вы считаете, что вводите правильные регистрационные данные, но не можете получить доступ к сайту, обратитесь к администратору ресурса. В этом случае лучше всего сделать скриншот проблемной страницы.
4. Иногда блокировка происходит на стороне провайдера, что тоже приводит к отказу в доступе и появлению сообщения с кодировкой 401. Для проверки можно попробовать авторизоваться на том же ресурсе с альтернативного ip-адреса (например, используя VPN). При подтверждении блокировки трафика свяжитесь с провайдером и следуйте его инструкциям.

Некоторые крупные интернет-ресурсы с большим количеством подписчиков используют дополнительные настройки для обеспечения безопасности доступа. К примеру, ваш аккаунт может быть заблокирован при многократных попытках неудачной авторизации. Слишком частые попытки законнектиться могут быть восприняты как действия бота. В этом случае вы увидите соответствующее сообщение, но можете быть просто переадресованы на страницу с кодом 401. Свяжитесь с администратором сайта и решите проблему.

Иногда простая перезагрузка проблемной страницы, выход из текущей сессии или использование другого веб-браузера полностью решают проблему с 401 ошибкой авторизации.

Устранение ошибки 401 администратором веб-ресурса 

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

• Обращение в службу поддержки хостинга сайта. Как и в случае возникновения проблем с провайдером, лучше всего подробно описать последовательность действий, приведших к появлению ошибки 401, приложить скриншот.
• При отсутствии проблем на стороне хостинг-провайдера можно внести следующие изменения в настройки сайта с помощью строки Disallow:/адрес проблемной страницы. Запретить индексацию страницам с ошибкой в «rоbоts.txt», после чего добавить в файл «.htассеss» строку такого типа:

Redirect 301 /oldpage.html http://site.com/newpage.html.

Где в поле /oldpage.html прописывается адрес проблемной страницы, а в http://site.com/newpage.html адрес страницы авторизации.

Таким образом вы перенаправите пользователей со всех страниц, которые выдают ошибку 401, на страницу начальной авторизации.

• Если после выполнения предыдущих рекомендаций пользователи при попытках авторизации все равно видят ошибку 401, то найдите на сервере файл «php.ini» и увеличьте время жизни сессии, изменив значения следующих параметров: «session.gc_maxlifetime» и «session.cookie_lifetime» на 1440 и 0 соответственно.
• Разработчики веб-ресурсов могут использовать более сложные методы авторизации и аутентификации доступа для создания дополнительной защиты по протоколу HTTP. Если устранить сбой простыми методами администрирования не удается, следует обратиться к специалистам, создававшим сайт, для внесения соответствующих изменений в код.

Хотя ошибка 401 и является проблемой на стороне клиента, ошибка пользователя на стороне сервера может привести к ложному требованию входа в систему. К примеру, сетевой администратор разрешит аутентификацию входа в систему всем пользователям, даже если это не требуется. В таком случае сообщение о несанкционированном доступе будет отображаться для всех, кто посещает сайт. Баг устраняется внесением соответствующих изменений в настройки.

Дополнительная информация об ошибке с кодом 401

Веб-серверы под управлением Microsoft IIS могут предоставить дополнительные данные об ошибке 401 Unauthorized в виде второго ряда цифр:

• 401, 1 – войти не удалось;
• 401, 2 – ошибка входа в систему из-за конфигурации сервера;
• 401, 3 – несанкционированный доступ из-за ACL на ресурс;
• 401, 501 – доступ запрещен: слишком много запросов с одного и того же клиентского IP; ограничение динамического IP-адреса – достигнут предел одновременных запросов и т.д.

Более подробную информацию об ошибке сервера 401 при использовании обычной проверки подлинности для подключения к веб-узлу, который размещен в службе MS IIS, смотрите здесь. 

Следующие сообщения также являются ошибками на стороне клиента и относятся к 401 ошибке:

• 400 Bad Request; 
• 403 Forbidden; 
• 404 Not Found;
• 408 Request Timeout.

Как видим, появление ошибки авторизации 401 Unauthorized не является критичным для рядового посетителя сайта и чаще всего устраняется самыми простыми способами. В более сложной ситуации оказываются администраторы и владельцы интернет-ресурсов, но и они в 100% случаев разберутся с данным багом путем изменения настроек или корректировки html-кода с привлечением разработчика сайта. 

Автор	Сообщение
10/08/2020 09:24:46      Тема: Re:Интеграция с 1С
Радик Даутов Зарегистрирован: 10/08/2020 06:39:22 Сообщений: 6 Оффлайн	nmzn1 wrote: Радик Даутов wrote:Здравствуйте. Подскажите, пожалуйста, как настроить работу в тестовом контуре. Данные для подключения получили, в программу внесли, обмен проходит без ошибок, никаких документов не приходит. Конфигурация УТ 11.4. Как протестировать работу? Откуда к нам придут документы? Может инструкция есть где-нибудь? Заранее спасибо здравствуйте какой инн могу глянуть созданы и прикреплены ли площадки в тесте — без этого не получиться тестить а потестить сначала нужно через веб, ссылки на тестовый веб здесь в блоке справа https://нмз1.рф/merkurii ИНН 025508318067. Организация уже работает в продуктивном контуре через веб, теперь настраиваем интеграцию в УТ
10/08/2020 09:31:00      Тема: Re:Интеграция с 1С
nmzn1 Зарегистрирован: 11/05/2017 09:25:20 Сообщений: 4971 Оффлайн	Радик Даутов wrote:ИНН 025508318067. Организация уже работает в продуктивном контуре через веб, теперь настраиваем интеграцию в УТ посмотрел в тесте — площадки или не созданы или не прикреплены к хс-у, нужно создать, потом прирепить Это сообщение было редактировано 1 раз. Последнее обновление произошло в 10/08/2020 09:31:16
10/08/2020 12:22:16      Тема: Re:Интеграция с 1С
Радик Даутов Зарегистрирован: 10/08/2020 06:39:22 Сообщений: 6 Оффлайн	nmzn1 wrote: Радик Даутов wrote:ИНН 025508318067. Организация уже работает в продуктивном контуре через веб, теперь настраиваем интеграцию в УТ посмотрел в тесте — площадки или не созданы или не прикреплены к хс-у, нужно создать, потом прирепить А как это делается? Не подскажете, может мануал?
10/08/2020 12:54:13      Тема: Re:Интеграция с 1С
nmzn1 Зарегистрирован: 11/05/2017 09:25:20 Сообщений: 4971 Оффлайн	Радик Даутов wrote:А как это делается? Не подскажете, может мануал? например здесь http://help.vetrf.ru/wiki/Инструкция_по_регистрации_производственных_объектов#.D0.92.D1.82.D0.BE.D1.80.D0.BE.D0.B9_.D1.88.D0.B0.D0.B3_.D1.80.D0.B5.D0.B3.D0.B8.D1.81.D1.82.D1.80.D0.B0.D1.86.D0.B8.D0.B8 тема на форуме была здесь https://fsvps.gov.ru/vetrf-forum/posts/list/150/7847.page тех.поддержка мерка 8 (4922) 52-99-29
10/08/2020 13:27:33      Тема: Re:Интеграция с 1С
Радик Даутов Зарегистрирован: 10/08/2020 06:39:22 Сообщений: 6 Оффлайн	nmzn1 wrote: Радик Даутов wrote:А как это делается? Не подскажете, может мануал? например здесь http://help.vetrf.ru/wiki/Инструкция_по_регистрации_производственных_объектов#.D0.92.D1.82.D0.BE.D1.80.D0.BE.D0.B9_.D1.88.D0.B0.D0.B3_.D1.80.D0.B5.D0.B3.D0.B8.D1.81.D1.82.D1.80.D0.B0.D1.86.D0.B8.D0.B8 тема на форуме была здесь https://fsvps.gov.ru/vetrf-forum/posts/list/150/7847.page тех.поддержка мерка 8 (4922) 52-99-29 спасибо
12/08/2020 08:46:23      Тема: Re:Интеграция с 1С
holnkys Зарегистрирован: 21/06/2018 08:14:47 Сообщений: 11 Оффлайн	Avik wrote:Здравствуйте! Кто пользуется типовой интеграцией 1С, подскажите один момент. При подборе «Записи складского журнала» в документе «Исходящая транспортная операция Ветис» открываются записи не конкретного товара а все записи принадлежащей группе товара. Что усложняет поиск нужной записи. К примеру для выбора записи складского журнала для товара «яйцо куриное пищевое С1» в списке отображаются записи для «яйцо куриное пищевое С2» и т.д. Так и должно быть, или здесь есть какая-то ошибка. 1С УТ 11.4 Заранее спасибо за ответ Аналогичная проблема Ут 11
12/08/2020 08:50:46      Тема: Re:Интеграция с 1С
MishaJ Зарегистрирован: 24/09/2018 22:26:05 Сообщений: 65 Оффлайн	Здравствуйте. Со вчерашнего дня у нас появилась следующая ошибка: Поиск по номеру ошибки ничего не дал, насколько я понимаю, это ответ от Меркурия, где и что надо исправить?
12/08/2020 09:17:59      Тема: Re:Интеграция с 1С
nmzn1 Зарегистрирован: 11/05/2017 09:25:20 Сообщений: 4971 Оффлайн	MishaJ wrote:Здравствуйте. Со вчерашнего дня у нас появилась следующая ошибка Поиск по номеру ошибки ничего не дал, насколько я понимаю, это ответ от Меркурия, где и что надо исправить? здравствуйте попробуйте узнать в тех.поддержке мерка 8 (4922) 52-99-29
12/08/2020 11:34:45      Тема: Re:Интеграция с 1С
MishaJ Зарегистрирован: 24/09/2018 22:26:05 Сообщений: 65 Оффлайн	holnkys wrote: Avik wrote:Здравствуйте! Кто пользуется типовой интеграцией 1С, подскажите один момент. При подборе «Записи складского журнала» в документе «Исходящая транспортная операция Ветис» открываются записи не конкретного товара а все записи принадлежащей группе товара. Что усложняет поиск нужной записи. К примеру для выбора записи складского журнала для товара «яйцо куриное пищевое С1» в списке отображаются записи для «яйцо куриное пищевое С2» и т.д. Так и должно быть, или здесь есть какая-то ошибка. 1С УТ 11.4 Заранее спасибо за ответ Аналогичная проблема Ут 11 Это не баг (с)… Для установки соответствия справочников Номенклатура (1С) и Продукция (Меркурий) есть регистр сведений СоответствиеНоменклатурыВЕТИС. Могу предположить, что или более 2-х позиций соответствия, или при открытии не правильно отрабатывает фильтр справочника «ЗаписиСкладскогоЖурналаВЕТИС». Это сообщение было редактировано 1 раз. Последнее обновление произошло в 12/08/2020 13:34:10
13/08/2020 07:45:57      Тема: Re:Интеграция с 1С
holnkys Зарегистрирован: 21/06/2018 08:14:47 Сообщений: 11 Оффлайн	Добрый день, используем УТ 11.4 с Ветис через вебсервер. Кто-то использует полный РИБ УТ с Меркурием. Какие-то есть проблемы? Как обмениваетесь с ВЕТИС, если каждая точка одновременно выгружает загружает ?
18/08/2020 15:11:56      Тема: Сообщение не принято ВетИС: Текст ошибки: Код состояния HTTP: 500. Код ошибки: APPL01011. Текст ошиб
Сергей Болбачан Зарегистрирован: 18/08/2020 14:59:08 Сообщений: 1 Оффлайн	1С БП3.0 прислали доступ к основному контуру. Хоз.субъект и предприятия достались. При попытке обмена транспортных операций выдает «Сообщение не принято ВетИС: Текст ошибки: Код состояния HTTP: 500. Код ошибки: APPL01011. Текст ошибки: Access denied Указан некорректный ключ доступа к интеграционному шлюзу..»
19/08/2020 15:58:43      Тема: Сообщение не принято ВетИС: Текст ошибки: Код состояния HTTP: 500. Код ошибки: APPL01011. Текст ошиб
nmzn1 Зарегистрирован: 11/05/2017 09:25:20 Сообщений: 4971 Оффлайн	Сергей Болбачан wrote:1С БП3.0 прислали доступ к основному контуру. Хоз.субъект и предприятия достались. При попытке обмена транспортных операций выдает «Сообщение не принято ВетИС: Текст ошибки: Код состояния HTTP: 500. Код ошибки: APPL01011. Текст ошибки: Access denied Указан некорректный ключ доступа к интеграционному шлюзу..» перепроверьте введённые данные по подключению, может где то пробел тех.поддержка мерка тел. 8 (4922) 52-99-29
20/08/2020 10:00:16      Тема: Re:Интеграция с 1С
mrkop Зарегистрирован: 16/07/2018 12:22:53 Сообщений: 9 Оффлайн	Доброго времени суток используем 1с Управление Ветеринарными сертификатыми Столкнулись с проблемой инвентаризации нескольких складских записей <Envelope xmlns=»http://schemas.xmlsoap.org/soap/envelope/» xmlnss=»http://www.w3.org/2001/XMLSchema» xmlnssi=»http://www.w3.org/2001/XMLSchema-instance»> <Body> <submitApplicationRequest xmlns=»http://api.vetrf.ru/schema/cdm/application/ws-definitions»> <apiKey>N2U2ZTA5NTAtODAxNi00ZDBlLThmODYtZDA5MDFjNzQ1NzVmMmMxZjI1NWEtY2ExNS00NTM3LWIyMWYtYmI1MmQ0NTlmMTgz</apiKey> <application xmlns=»http://api.vetrf.ru/schema/cdm/application»> <serviceId>mercury-g2b.service:2.1</serviceId> <issuerId>2c1f255a-ca15-4537-b21f-bb52d459f183</issuerId> <issueDate>2020-08-20T01:07:20</issueDate> <data> <resolveDiscrepancyRequest xmlns=»http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2″> <localTransactionId>595d9c10-e268-11ea-a25a-7085c2409d3e</localTransactionId> <initiator xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <d7p1:login>groshev_mj_180304</d7p1:login> </initiator> <enterprise xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>7eaa7715-caf0-41e5-bcc2-54a9b57a5bf3</guid> </enterprise> <inventoryDate>2020-08-20T01:07:20</inventoryDate> <responsible xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <d7p1:login>groshev_mj_180304</d7p1:login> </responsible> <stockDiscrepancy xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <d7p1:resultingList count=»1″ total=»1″ offset=»0″> <d7p1:stockEntry> <uuid xmlns=»http://api.vetrf.ru/schema/cdm/base»>0d071a27-d952-4b73-aa4b-a7397aeaf4a2</uuid> <d7p1:batch> <d7p1:productType>1</d7p1:productType> <d7p1:product xmlns:d11p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>57a674fd-ca2b-c523-6853-72d27b4ae32c</guid> </d7p1:product> <d7p1:subProduct xmlns:d11p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>1d17cba8-77e5-5cea-8ba3-3e29b5900697</guid> </d7p1:subProduct> <d7p1:productItem xmlns:d11p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>cb9e8f6f-8d8d-485f-b7b7-9958a0f82012</guid> </d7p1:productItem> <d7p1:volume>9.18</d7p1:volume> <d7p1:unit xmlns:d11p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>21ed96c9-337b-4a27-8761-c6e6ad3c9f5b</guid> </d7p1:unit> <d7p1:dateOfProduction> <d7p1:firstDate xmlns:d12p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d12p1:year>2020</d12p1:year> <d12p1:month>4</d12p1:month> <d12p1:day>22</d12p1:day> </d7p1:firstDate> <d7p1:secondDate xmlns:d12p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d12p1:year>2020</d12p1:year> <d12p1:month>6</d12p1:month> <d12p1:day>2</d12p1:day> </d7p1:secondDate> </d7p1:dateOfProduction> <d7p1:expiryDate> <d7p1:firstDate xmlns:d12p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d12p1:year>2020</d12p1:year> <d12p1:month>10</d12p1:month> <d12p1:day>21</d12p1:day> </d7p1:firstDate> <d7p1:secondDate xmlns:d12p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d12p1:year>2020</d12p1:year> <d12p1:month>12</d12p1:month> <d12p1:day>1</d12p1:day> </d7p1:secondDate> </d7p1:expiryDate> <d7p1:perishable>false</d7p1:perishable> <d7p1:origin> <d7p1:country xmlns:d12p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>74a3cbb1-56fa-94f3-ab3f-e8db4940d96b</guid> </d7p1:country> </d7p1:origin> <d7p1:lowGradeCargo>false</d7p1:lowGradeCargo> <d7p1:packageList xmlns:d11p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d11p1:package> <d11p1:level>1</d11p1:level> <d11p1:packingType> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>fedf4328-053c-11e1-99b4-d8d385fbc9e8</guid> </d11p1:packingType> <d11p1:quantity>0</d11p1:quantity> <d11p1:productMarks class=»BUNDLE»>этикетка ООО»ГРАНД ФУД»</d11p1:productMarks> <d11p1:productMarks class=»BUNDLE»>этикетка ООО «ГРАНД ФУД»</d11p1:productMarks> </d11p1:package> </d7p1:packageList> </d7p1:batch> </d7p1:stockEntry> </d7p1:resultingList> </stockDiscrepancy> <discrepancyReport xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <d7p1:issueSeries/> <d7p1:issueNumber/> <d7p1:reason> <d7p1:name/> </d7p1:reason> <d7p1:description/> </discrepancyReport> </resolveDiscrepancyRequest> </data> </application> </submitApplicationRequest> </Body> </Envelope> и в итоге получаю MERC24019 В запросе для вида продукции указан идентификатор устаревшей версии записи реестра РСХН. <?xml version=»1.0″ encoding=»UTF-8″?> <soap:Envelope xmlns:soap=»http://schemas.xmlsoap.org/soap/envelope/»><soap:Body><receiveApplicationResultResponse xmlns=»http://api.vetrf.ru/schema/cdm/application/ws-definitions»> <application xmlns=»http://api.vetrf.ru/schema/cdm/application»> <applicationId>9879fada-9bfa-4870-bc52-59ab7921e659</applicationId> <status>REJECTED</status> <serviceId>mercury-g2b.service</serviceId> <issuerId>2c1f255a-ca15-4537-b21f-bb52d459f183</issuerId> <issueDate>2020-08-20T01:07:20+03:00</issueDate> <rcvDate>2020-08-20T03:08:26+03:00</rcvDate> <prdcRsltDate>2020-08-20T03:08:27+03:00</prdcRsltDate> <apl:errors xmlns:apl=»http://api.vetrf.ru/schema/cdm/application»> <apl:error code=»MERC24019″>В запросе для вида продукции указан идентификатор устаревшей версии записи реестра РСХН.</apl:error> </apl:errors> </application> </receiveApplicationResultResponse></soap:Body></soap:Envelope> Версии записей GUID и в базе и в меркурий совпадают. Записи обновлял, продукцию актуализировал. Как что посмотреть можно в этом случае? 5 позиций не хотят инвентарихироваться((( Вручную на сайте пожалуйста, а из базы ругаются, как в ручню версии выстаивть?
20/08/2020 10:22:40      Тема: Re:Интеграция с 1С
serg882 Зарегистрирован: 26/10/2017 11:52:09 Сообщений: 166 Оффлайн	У вас ответ Меркурия не на заявку «595d9c10-e268-11ea-a25a-7085c2409d3e», а на «9879fada-9bfa-4870-bc52-59ab7921e659», поэтому нельзя ответить где ошибка. Сверьте GUID subProduct.
20/08/2020 11:26:42      Тема: Re:Интеграция с 1С
mrkop Зарегистрирован: 16/07/2018 12:22:53 Сообщений: 9 Оффлайн	Заявка. <Envelope xmlns=»http://schemas.xmlsoap.org/soap/envelope/» xmlnss=»http://www.w3.org/2001/XMLSchema» xmlnssi=»http://www.w3.org/2001/XMLSchema-instance»> <Body> <submitApplicationRequest xmlns=»http://api.vetrf.ru/schema/cdm/application/ws-definitions»> <apiKey>N2U2ZTA5NTAtODAxNi00ZDBlLThmODYtZDA5MDFjNzQ1NzVmMmMxZjI1NWEtY2ExNS00NTM3LWIyMWYtYmI1MmQ0NTlmMTgz</apiKey> <application xmlns=»http://api.vetrf.ru/schema/cdm/application»> <serviceId>mercury-g2b.service:2.1</serviceId> <issuerId>2c1f255a-ca15-4537-b21f-bb52d459f183</issuerId> <issueDate>2020-08-20T11:08:01</issueDate> <data> <resolveDiscrepancyRequest xmlns=»http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2″> <localTransactionId>4e627ede-e2bc-11ea-a25a-7085c2409d3e</localTransactionId> <initiator xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <d7p1:login>groshev_mj_180304</d7p1:login> </initiator> <enterprise xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>7eaa7715-caf0-41e5-bcc2-54a9b57a5bf3</guid> </enterprise> <inventoryDate>2020-08-20T11:08:01</inventoryDate> <responsible xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <d7p1:login>groshev_mj_180304</d7p1:login> </responsible> <stockDiscrepancy xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <d7p1:resultingList count=»1″ total=»1″ offset=»0″> <d7p1:stockEntry> <uuid xmlns=»http://api.vetrf.ru/schema/cdm/base»>0d071a27-d952-4b73-aa4b-a7397aeaf4a2</uuid> <d7p1:batch> <d7p1:productType>1</d7p1:productType> <d7p1:product xmlns:d11p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>57a674fd-ca2b-c523-6853-72d27b4ae32c</guid> </d7p1:product> <d7p1:subProduct xmlns:d11p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>1d17cba8-77e5-5cea-8ba3-3e29b5900697</guid> </d7p1:subProduct> <d7p1:productItem xmlns:d11p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>cb9e8f6f-8d8d-485f-b7b7-9958a0f82012</guid> </d7p1:productItem> <d7p1:volume>9.18</d7p1:volume> <d7p1:unit xmlns:d11p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>21ed96c9-337b-4a27-8761-c6e6ad3c9f5b</guid> </d7p1:unit> <d7p1:dateOfProduction> <d7p1:firstDate xmlns:d12p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d12p1:year>2020</d12p1:year> <d12p1:month>4</d12p1:month> <d12p1:day>22</d12p1:day> </d7p1:firstDate> <d7p1:secondDate xmlns:d12p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d12p1:year>2020</d12p1:year> <d12p1:month>6</d12p1:month> <d12p1:day>2</d12p1:day> </d7p1:secondDate> </d7p1:dateOfProduction> <d7p1:expiryDate> <d7p1:firstDate xmlns:d12p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d12p1:year>2020</d12p1:year> <d12p1:month>10</d12p1:month> <d12p1:day>21</d12p1:day> </d7p1:firstDate> <d7p1:secondDate xmlns:d12p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d12p1:year>2020</d12p1:year> <d12p1:month>12</d12p1:month> <d12p1:day>1</d12p1:day> </d7p1:secondDate> </d7p1:expiryDate> <d7p1:perishable>false</d7p1:perishable> <d7p1:origin> <d7p1:country xmlns:d12p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>74a3cbb1-56fa-94f3-ab3f-e8db4940d96b</guid> </d7p1:country> </d7p1:origin> <d7p1:lowGradeCargo>false</d7p1:lowGradeCargo> <d7p1:packageList xmlns:d11p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d11p1:package> <d11p1:level>1</d11p1:level> <d11p1:packingType> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>fedf4328-053c-11e1-99b4-d8d385fbc9e8</guid> </d11p1:packingType> <d11p1:quantity>0</d11p1:quantity> <d11p1:productMarks class=»BUNDLE»>этикетка ООО»ГРАНД ФУД»</d11p1:productMarks> <d11p1:productMarks class=»BUNDLE»>этикетка ООО «ГРАНД ФУД»</d11p1:productMarks> </d11p1:package> </d7p1:packageList> </d7p1:batch> </d7p1:stockEntry> </d7p1:resultingList> </stockDiscrepancy> <discrepancyReport xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <d7p1:issueSeries/> <d7p1:issueNumber/> <d7p1:reason> <d7p1:name/> </d7p1:reason> <d7p1:description/> </discrepancyReport> </resolveDiscrepancyRequest> </data> </application> </submitApplicationRequest> </Body> </Envelope> ответ <?xml version=»1.0″ encoding=»UTF-8″?> <soap:Envelope xmlns:soap=»http://schemas.xmlsoap.org/soap/envelope/»><soap:Body><receiveApplicationResultResponse xmlns=»http://api.vetrf.ru/schema/cdm/application/ws-definitions»> <application xmlns=»http://api.vetrf.ru/schema/cdm/application»> <applicationId>cc33508d-1250-4e91-a9ba-8ca4f9a33043</applicationId> <status>REJECTED</status> <serviceId>mercury-g2b.service</serviceId> <issuerId>2c1f255a-ca15-4537-b21f-bb52d459f183</issuerId> <issueDate>2020-08-20T11:08:01+03:00</issueDate> <rcvDate>2020-08-20T11:22:06+03:00</rcvDate> <prdcRsltDate>2020-08-20T11:22:06+03:00</prdcRsltDate> <apl:errors xmlns:apl=»http://api.vetrf.ru/schema/cdm/application»> <apl:error code=»MERC24019″>В запросе для вида продукции указан идентификатор устаревшей версии записи реестра РСХН.</apl:error> </apl:errors> </application> </receiveApplicationResultResponse></soap:Body></soap:Envelope> https://prnt.sc/u2p9ra GUID subProduct. А где в WEB версии это можно проверить? Это сообщение было редактировано 1 раз. Последнее обновление произошло в 20/08/2020 11:27:52

Страница с ошибкой при обращении к WordPress-сайту всегда вызывает неудобства, вне зависимости от того, ваш это сайт или чужой. Как и в случае со многими другими кодами ответов HTTP, ошибка 401 не содержит детальных данных для диагностики и решения проблемы.

Ошибка 401 может появиться в любом браузере. В большинстве случаев ее легко решить.

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

Итак, приступим!

Код ошибки 401 – что это?

Коды состояния HTTP 400 возникают в случае проблем с выполнением запросов. В частности, ошибка 401 появляется, когда браузер отказывает вам в доступе к странице, которую вы хотите посетить.

В результате вместо загрузки страниц браузер выведет сообщение об ошибке. Ошибки 401 могут возникать в любом браузере, потому отображаемое сообщение может варьироваться.

К примеру, в Chrome и Edge вы, скорее всего, увидите иконку бумаги с простым сообщением о том, что запрашиваемая страница не отвечает. Вы увидите фразу «HTTP Error 401». Вам будет предложено связаться с владельцем сайта, если ошибка не пропадет:

В иных случаях и в других браузерах вы можете получить менее дружелюбное предупреждение. К примеру, может выводиться пустая страница с сообщением «401 Authorization Required»:

Другие вариации текста:

• HTTP 401 Error – Unauthorized
• 401 Unauthorized
• Access Denied

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

Эта ошибка похожа на HTTP 403 Forbidden Error, когда доступ к сайту для пользователя запрещен. Однако, в отличие от ошибки 403, сообщение об ошибке 401 указывает, что процесс аутентификации завершился неудачно.

Код ошибки передается через заголовок WWW-Authenticate, который отвечает за определение метода аутентификации, используемого для предоставления доступа к веб-странице или ресурсу.

Что вызывает ошибку 401

Если вы столкнулись с кодом ошибки в кодах 400, вы должны знать, что проблема произошла на стороне клиента (либо на стороне браузера). Случается, что виновником проблемы является браузер, но так бывает не всегда. Об этом мы еще расскажем позже.

Ошибки 401 возникают на ресурсах с ограниченным доступом – к примеру, на страницах, защищенных паролем. Потому можно предположить, что причина проблемы связана с данными аутентификации.

Устаревшие Cookie и кэш браузера

Одной из наиболее распространенных причин возникновения ошибки 401 является то, что кэш и файлы cookie вашего браузера устарели, что не позволяет выполнить авторизацию. Если ваш браузер использует недействительные данные для авторизации (либо вообще их не использует их), сервер отклонит запрос.

Несовместимые плагины

Также бывают ситуации, когда ошибка вызвана несовместимостью плагинов или какими-либо сбоями в них. К примеру, плагин безопасности может ошибочно принять вашу попытку входа за вредоносную активность, а потому будет возвращена ошибка 401 для защиты страницы.

Неверный URL или устаревшая ссылка

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

Как исправить ошибку 401 (5 методов)

Теперь, когда мы разобрались с причинами ошибки 401, пришло время обсудить, как ее устранить.

Давайте рассмотрим 5 методов, которые вы можете использовать.

1. Проверьте ваш URL.

Начнем с самого простого потенциального решения: убедитесь, что вы использовали верный URL. Это может выглядеть банально, но 401 ошибки нередко появляются, если URL-адрес был введен неправильно.

Еще один вариант: ссылка, которую вы использовали для перехода на запрашиваемую страницу, указывает на неправильный URL. К примеру, ссылка устарела, ведет на страницу, которой больше нет (и редиректов не задано).

Стоит тщательно перепроверить URL-адрес, который вы использовали. Если вы набирали адрес самостоятельно, убедитесь, что все написано безошибочно. Если вы переходили по ссылке, убедитесь в том, что она ведет на страницу, к которой вы хотите получить доступ (либо попробуйте перейти на эту страницу непосредственно через сайт).

1. Почистите кэш браузера.

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

Как мы уже говорили выше, одной из распространенных причин появления ошибки 401 являются устаревшие или неправильные данные кэша или cookies. Потому, если URL введен верно, следующий шаг – чистка кэша браузера.

В итоге вы удалите любую недействительную информацию, которая хранится локально в вашем браузере и может приводить к прерываниям процесса аутентификации.  Аналогично, файлы cookie вашего браузера могут содержать аутентификационные данные, которые нужно обновить.

Если вы пользуетесь Chrome, вам нужно щелкнуть по иконке с меню в правом верхнем углу браузера и выбрать пункт Settings. В разделе «Privacy and security» нажмите «Clear browsing data:»

Далее вводим URL требуемого сайта и очищаем для него данные.

В других браузерах процесс очистки кэша и cookie может отличаться. К примеру, в Firefox нужно щелкать по иконке с библиотекой и выбирать History > Clear Recent History:

Информацию по остальным браузерам вы можете найти в поисковиках.

1. Очистка DNS.

Еще один метод, который вы можете попробовать для устранения ошибки 401 – это очистка DNS. Эта причина встречается относительно редко, но стоит попробовать и такой подход, особенно если первые два ничего не дали.

Чтобы очистить DNS, перейдите в Windows к меню «Пуск» и там уже введите в строку поиска cmd. Нажмите Enter. Откроется командная строка. Далее вставьте команду ipconfig/flushdns, после чего снова нажмите Enter.

Если вы пользуетесь Mac, вы можете открыть командную строку следующим образом: Finder > Applications > Utilities > Terminal.

Введите команду sudo killall -HUP mDNSResponder и нажмите Enter. Затем вы можете обновить страницу, чтобы посмотреть, пропала ли ошибка 401 или нет.

1. Деактивируйте ваши плагины

Проблема может возникать и по вине плагинов.

Некоторые плагины, особенно связанные с безопасностью, могут выдавать ошибку 401 при подозрении на вредоносную активность. Также у них могут быть проблемы с совместимостью. Потому лучше всего деактивировать все плагины и посмотреть, будет ли страница работать.

Вы можете деактивировать все плагины разом, перейдя в раздел Plugins > Installed Plugins в консоли WordPress. Выберите все плагины и в меню Bulk Actions задайте Deactivate, после чего щелкните по кнопке Apply:

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

Далее вы уже можете либо удалить плагин, либо написать его разработчикам, чтобы они предоставили рабочее решение.

1. Проверьте заголовок WWW-Authenticate

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

Как мы уже писали ранее, ответ 401 передается через заголовок WWW-Authenticate, который отображается как “WWW-Authenticate: <type> realm=<realm>”. Он включает в себя строки данных, указывающие на то, какой тип аутентификации требуется для предоставления доступа.

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

Перейдите на страницу с ошибкой 401 и откройте консоль разработчика в Chrome. Вы можете щелкнуть правой кнопкой мыши на странице и выбрать Inspect (Ctrl+Shift+J).

Далее перейдите на вкладку Network и перезагрузите страницу. Это позволит сгенерировать список ресурсов. Выберите заголовок Status, чтобы отсортировать таблицу, и найдите код 401:

Выберите данную запись, после чего перейдите на вкладку Headers. В Response Headers найдите заголовок WWW-Authenticate:

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

К примеру, в приведенном выше примере мы видим, что схема аутентификации задана как «Basic». Это означает, что запрос аутентификации требует только ID и password. Для получения более подробной информации и инструкций мы рекомендуем обратиться к HTTP Authentication Scheme Registry.

Источник: kinsta.com

Категория ~
Что делать (ошибки и проблемы)

– Автор:

Игорь (Администратор)

Сегодня рассмотрим такую специфическую ошибку как 401 Unauthorized Error. Почему специфическую? Потому что обычные пользователи интернета практически никогда не встречаются с данной ошибкой. Но обо всем по порядку.

Что значит ошибка 401 Unauthorized?

Ошибка 401 Unauthorized («Отказ в доступе») — эта ошибка означает, что при попытке открыть веб-страницу сайта пользователем возникли проблемы с его авторизацией или аутентификацией.

Основная суть. Пользователь пытается открыть страницу. Сайт возвращает страницу с HTTP заголовком WWW-Authenticate (кстати, страница также с кодом 401 Unauthorized), в котором перечислены параметры системы аутентификации. Браузер запрашивает логин и пароль у пользователя, которые передаются в заголовке Authorization обратно к сайту (в соответствии с ранее полученными настройками системы безопасности). Если проверка прошла, то пользователю предоставляется дальше доступ к странице. В противном случае появляется ошибка 401 Unauthorized.

Кстати, стоит понимать, что данная ошибка отличается от 403 Forbidden, хотя и также связана с настройками безопасности.

Возможные причины возникновения ошибки 401 Unauthorized:

1. Некорректно введенные логин или пароль (или их отсутствие). Пользователь что-то некорректно ввел.

2. Недостаточно прав для доступа. Например, в каждом сайте вполне нормальным явлением считается то, что у обычного пользователя нет доступа к административной части сайта.

3. Ошибки в настройках или коде сайта. Такое тоже бывает.

Варианты возможных текстовых уведомлений:

1. HTTP Error 401 — Ошибка авторизации.

2. Требуется авторизация.

3. 401 Несанкционированный доступ.

4. 401 Unauthorized.

5. Authorization Required.

Что делать при ошибке 401 Unauthorized, если вы обычный посетитель сайта?

Рассмотрим что вы можете сделать, если вы обычный пользователь и столкнулись с ошибкой 401 Unauthorized:

1. Введите корректные логин и пароль. Ошибка 401 означает ошибку в авторизации или аутентификации, поэтому стоит проверить правильность введенных вами логина и пароля.

2. Проверьте корректность URL адреса страницы веб-сайта. Если вы не ожидали увидеть 401 Unauthorized (скажем, постоянно открывали сайт без проблем), то вполне нормальным действием будет проверить корректность адреса.

3. Попробуйте открыть страницу через время или с другого браузера. Вполне может быть так, что автор сайта что-то делает с этим самым веб-сайтом. Поэтому стоит подождать какое-то время и попробовать еще раз открыть веб-страницу. Так же может быть так, что ошибка 401 возникает из-за браузера (мало ли чего), поэтому стоит попробовать открыть страницу другим браузером (или с другого компьютера).

Кстати, обзор в тему Зачем пользователю несколько браузеров?

4. Напишите автору сайта. Как минимум узнаете причину или возможное время восстановления доступа.

Как исправить ошибку 401 Unauthorized, если вы владелец сайта?

Теперь рассмотрим как исправить ошибку 401 Unauthorized владельцу сайта:

1. Проверьте URL и логин с паролем. Владелец сайта это тоже пользователь сайта, поэтому проверить адрес страницы и корректность ввода логина с паролем будет не лишним действием.

2. Проверьте настройки и код сайта. Если же вам сайт делал кто-то иной, то попросите его проверить.

3. Напишите хостеру. Если вы все проверили и проблем не обнаружили, то нужно писать хостеру.

Понравилась заметка? Тогда время подписываться в социальных сетях и делать репосты!

☕ Понравился обзор? Поделитесь с друзьями!

Добавить комментарий / отзыв

  

Звездец

02.05.18 — 16:38

Ветис уже скоро. А что-то вокруг тишина. В программах даже что-то появилось, а на ИТС ни одной инструкции. Все ждут? или может кто-то что-нибудь делает для подготовки?

  

EuVod

901 — 06.07.18 — 13:48

  

spectre1978

902 — 06.07.18 — 13:55

(901) 401 не видел, но вообще HTTP ошибки бывают. 502 чаще всего.

  

NSSerg

903 — 06.07.18 — 14:01

  

NSSerg

904 — 06.07.18 — 14:05

  

NSSerg

905 — 06.07.18 — 14:20

  

NSSerg

906 — 06.07.18 — 14:33

Походу у них действительно сломался метод. Теперь если UUID в базе есть, то отдает всё по формату, с кодом ответа 200, если UUID нет, то получаем код ответа 500, и внутреннюю ошибку сервера.

  

NSSerg

907 — 06.07.18 — 15:47

  

NSSerg

908 — 06.07.18 — 15:58

Они что-ли все старые тикеты порезали в базе?

  

spectre1978

909 — 06.07.18 — 16:05

хмм… я, честно говоря, никогда и не рассчитывал на то что тикеты будут храниться сколько-то долгое время. Это же невероятный объем мусора. Кому надо — перезапросят.

  

NSSerg

910 — 06.07.18 — 16:12

  

spectre1978

911 — 06.07.18 — 16:14

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

  

NSSerg

912 — 06.07.18 — 16:15

  

NSSerg

913 — 06.07.18 — 16:16

  

Вафель

914 — 06.07.18 — 16:21

(912) так они просто xml валидируют, поэтому  (905) и не проходит

  

NSSerg

915 — 06.07.18 — 16:24

  

Вафель

916 — 06.07.18 — 16:25

(915) тут согласен

  

spectre1978

917 — 06.07.18 — 16:26

(912) ошибка 500 это ошибка веб-сервера, которая не определена явно другими 5ХХ ошибками. Похоже что они пихнули туда результаты валидации XML, который им приходит в SOAP-пакетах. Собственно, я не вижу причин почему так делать нельзя.

  

NSSerg

918 — 06.07.18 — 16:27

  

spectre1978

919 — 06.07.18 — 16:33

(913) я сохраняю UUIDы ВСД. Привязываю их к накладной. Это статическая штука, я думаю что они будут храниться по крайней мере до тех пор, пока существует партия. Что касаемо тикетов — то это та фигня, которая отдается после submitApplicationRequest? Я правильно понял? Тогда я бы не рассчитывал на то что это будет доступно долго.

  

NSSerg

920 — 06.07.18 — 16:40

(919) Теперь и я сохраняю. А все старые похерены.

  

spectre1978

921 — 06.07.18 — 16:40

как думается мне, их нужно передавать в некое фоновое задание, которое будет немедленно добиваться по ним ответа. Как только ответ есть — данные записываются в базу, тикет уничтожается. Т.е. есть очередь тикетов, в хвост пристраиваются новые, а голова постоянно очищается путем получения ответов. Как-то так. При завершении программы юзер должен дожидаться чтобы все тикеты были отработаны, иначе ругаться громко и матом — ибо по факту это будет означать что результаты выполнения всех необработанных заявок будут утеряны.

  

spectre1978

922 — 06.07.18 — 16:45

это я про тикеты. А UUIDы я сохранял изначально. Помимо UUIDов, я подбираю из веток еще кое-какое барахлишко для локальной печати веток (без участия Меркурия).

  

NSSerg

923 — 06.07.18 — 17:13

  

NSSerg

924 — 06.07.18 — 17:30

Короче в итоге вернул обратно — код 500 у меня опять равносилен либо пустому запросу, либо REJECTED. Даже не разбираю его. Что конечно-же неправильно.

  

spectre1978

925 — 06.07.18 — 20:11

Вопрос. «Зелененькую машинку» кто-нибудь на API реализовывал? Т.е. возможно ли API двойкой как-нибудь получить все непогашенные входящие? Пока приходит в голову только getVetDocumentListChangesRequest за ближайшие несколько дней и ручками отобрать из массива непогашенные. Но это какое-то извращение…

  

spectre1978

926 — 07.07.18 — 17:39

Похоже, что ответ на мой вопрос кроется в версии API 2.1. Чует мое сердце, что надо переползать…

  

spectre1978

927 — 07.07.18 — 21:15

  

spectre1978

928 — 08.07.18 — 09:55

По (925) вопрос снят, разобрался

  

ProxyInspector

929 — 08.07.18 — 14:24

(927) Интересная встреча. Но это только десяток крупнейших производителей и сетей.Каждый из которых вбухал по 100 млн. руб и имеет процент гашения на уровне 30% — 70%. А каково остальным сотням тысяч предприятий. И что будет с системой Меркурий, когда эти предприятия начнут активно работать.

  

ProxyInspector

930 — 08.07.18 — 14:27

Лично у нас распределительный центр на 50 магазинов. На сегодняшний день мы получаем только на 10% продукции входящие ВСД, и изготовляем 0% исходящих ВСД

  

timurhv

931 — 09.07.18 — 12:09

  

spectre1978

932 — 09.07.18 — 12:32

(931) Вот что животворящий выкуп акций ВТБ делает!

  

mishaPH

Модератор

933 — 09.07.18 — 12:40

  

spectre1978

934 — 09.07.18 — 12:42

(933) там странная история. Вы статистику смотрели? Магнит обрабатывает четверть всего трафика ВСД. А Х5 — несколько процентов.

  

mishaPH

Модератор

935 — 09.07.18 — 12:50

(934) обрабатывает или использует ВСД?

  

spectre1978

936 — 09.07.18 — 12:55

  

mishaPH

Модератор

937 — 09.07.18 — 12:57

  

Genayo

938 — 09.07.18 — 12:59

(937) Видимо, у x5 прямых поставок в магазины больше, чем у Магнита.

  

spectre1978

939 — 09.07.18 — 13:01

  

mishaPH

Модератор

940 — 09.07.18 — 13:05

  

ProxyInspector

941 — 09.07.18 — 13:08

  

mishaPH

Модератор

942 — 09.07.18 — 13:11

(941) если прибавить еще алкоголь. то Ит трафик у магазина огого

  

timurhv

943 — 09.07.18 — 13:12

(933) Я думаю, либо они часть серверов сами купили и поставили Россельхозу под Меркурий под свои нужды, либо пришла директива выделить им сервера чисто под них. Иначе ситуация когда никто не может получить ВСД, а у них все хорошо — выглядит странной.

  

spectre1978

944 — 09.07.18 — 13:13

(943) ну да. Причем если Галицкий еще мог заупрямиться, то теперь-то там зеленая улица. Скажут — сделают.

  

ProxyInspector

945 — 09.07.18 — 13:14

Либо они сами не понимают в какой ж-пе находятся.

  

mishaPH

Модератор

946 — 09.07.18 — 13:18

(943) ну это да. что-то тут явно не так

  

mishaPH

Модератор

947 — 09.07.18 — 13:47

  

timurhv

948 — 09.07.18 — 13:50

(947) Больше всех производители страдают, как собственно обычно.

  

mishaPH

Модератор

949 — 09.07.18 — 13:53

  

timurhv

950 — 09.07.18 — 14:02

(949) Между площадками при производстве ничего не перевезешь толком. Через дорогу перевезти — тоже нужно ВСД выписать.

  

mishaPH

Модератор

951 — 09.07.18 — 16:09

(950) знаю. у нас 3 завода 2-4 км друг от друга. и все 3 находятся в разных раонных ветслужбах.

  

ProxyInspector

952 — 09.07.18 — 16:22

У меня сейчас Ветис умер. При этом умер он на функции getProductByGuid. Это основополагающая функция. Если она умирает, тогда останавливается весь Ветис. При этом умирал он медленно. Сначала умерла функция getProductByGuid, а через несколько минут — Ветис

  

NSSerg

953 — 09.07.18 — 16:27

(952) У меня если продукт не может получить по guid-у (а проверяет active обязательно, ибо выводят из базы продукцию), тогда инвентаризация, и отгрузка по ТНВЭД (третьему уровню). Ничего не останавливается.

  

NSSerg

954 — 09.07.18 — 16:29

И, кстати, только что делал большую ВСД на 41 позицию — всё нормально, ушло с гуидами. Значит getProductByGuid работает.

  

NSSerg

955 — 09.07.18 — 16:55

  

Genayo

956 — 09.07.18 — 18:07

(954) Похоже, что у них в разных регионах разные сервера, и балансировка нагрузки не очень работает…

  

spectre1978

957 — 09.07.18 — 19:08

(955) Вроде позавчера 12 было… Чет новое?

  

ProxyInspector

958 — 10.07.18 — 11:44

  

NSSerg

959 — 10.07.18 — 13:18

  

NSSerg

960 — 10.07.18 — 13:25

  

timurhv

961 — 10.07.18 — 13:26

(960) Назначение какое указали?

  

NSSerg

962 — 10.07.18 — 13:31

(961) Как и все остальные. Реализация в пищу людям

  

NSSerg

963 — 10.07.18 — 14:36

(960) Это была ошибка в меркурии, вроде по нашему обращению поправили. Действительно под этим ТНВЭД уполномоченным не давала выписывать. Завтра проверим.

  

NSSerg

964 — 12.07.18 — 15:46

  

spectre1978

965 — 12.07.18 — 16:23

(964) очевидно, все как-то приноровились и работают…

  

birkoFFFF

966 — 12.07.18 — 16:55

  

spectre1978

967 — 12.07.18 — 17:10

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

  

spectre1978

968 — 12.07.18 — 17:11

вот про лабораторные исследования надо уточнить. По-моему, я при запросе партий это дело проверяю, но я работаю через getStockEntryList, не через Changes. Так что меня коснуться не должно

  

spectre1978

969 — 12.07.18 — 17:18

Кстати, рекомендую почитать список обновлений уважаемому NSSerg. Там первое обновление как раз по его душу — появилась возможность указывать иностранное предприятие-поставщика без указания его GUID для входящей партии.

  

NSSerg

970 — 12.07.18 — 17:35

  

ProxyInspector

971 — 13.07.18 — 14:56

  

NSSerg

972 — 13.07.18 — 15:30

(971) нет. У меня тот же вопрос, но походу нет, у тебя вместе с ошибкой возвращается её текстовое описание.

  

spectre1978

973 — 13.07.18 — 15:36

(971) так вроде в BusinessError возвращаются текстовые описания. Или у вас провайдер, а не API?

  

ProxyInspector

974 — 13.07.18 — 15:40

У меня в IncomingOperation — оформление входящей партии возвращает только КодОшибки.

  

ProxyInspector

975 — 13.07.18 — 16:32

  

ProxyInspector

976 — 13.07.18 — 16:39

В справке написано «В запросе для номенклатуры продукции указан идентификатор устаревшей версии записи реестра РСХН» и как это перевести на русский язык?

  

NSSerg

977 — 13.07.18 — 16:45

(975) это значит продукция выведена из реестра РСХН?

  

ProxyInspector

978 — 13.07.18 — 16:45

Через WEB Я погасил эту ВСД. Где-то проскакивало, что в Меркурии утверждают, что такую ВСД можно погасить только через WEB интерфейс

  

ProxyInspector

979 — 13.07.18 — 16:47

Через API не смог, хотя продукция полностью обновлена.

  

spectre1978

980 — 13.07.18 — 18:59

(975)(976)(977) скорее всего это означает, что в запросе для продукции указали UUID продукции, а не GUID, и этот UUID является идентификатором непоследней версии продукции. Я не Ванга, но думаю, что произошло следующее: ваши контрики выписали ВСД, используя последний на тот момент UUID продукции. А потом, пока ВСД летел к вам, что-то подправили в справочнике для этой номенклатуры — название там поменяли или еще чего, может, просто ОК нажали. В результате для соответствующего GUID номенклатуры образовалась новая последняя версия с новым UUID, а тот UUID, который был в ВСД — стал неактуальным. Чтобы это полечить, наверно, нужно при приемке либо сменить UUID на последний, либо очистить его и заполнить GUID.

  

spectre1978

981 — 13.07.18 — 19:01

Кстати! Ща скажу важную вещь, на которую напоролся. Если для какой-то версионной сущности в запросе заполнен и GUID, и UUID, приоритет у UUID! Так что если не хотите ловить ошибки с устаревшей версией, не пользуйтесь UUID без крайней необходимости.

  

Garykom

982 — 13.07.18 — 19:02

  

spectre1978

983 — 13.07.18 — 19:12

+ (979) чтобы было более понятно, как это работает, надо понимать, как работает механизм Versioning Entity в Ветис.АПИ. Грубо говоря, каждая номенклатура это связный список элементов, каждый из которых содержит GUID и UUID. GUID уникален для каждого элемента справочника номенклатуры, это типа как код в справочнике 1С. А UUID уникален для каждого элемента списка. Когда создается новый элемент номенклатуры, в списке создается первый элемент. Первая версия. Она активна и не содержит ссылок на предыдущие и следующие элементы. Потом решили ее подправить. Создается второй элемент списка, ссылающийся на первый. GUID у него тот же, а UUID уже другой. И теперь уже второй элемент активен, а первый нет. Второй ссылается на первый, первый на второй. Если запустили процедуру удаления — признак активности у последнего элемента снимается, т.е. все элементы в списке тупо неактивные, а физически ничего не удалилось. Старые документы могут ссылаться на неактивные версии номенклатуры, а новые нет — будет вот эта самая ваша ошибка с устаревшей версией. Как-то так это все работает…

  

Обработка

984 — 13.07.18 — 19:13

  

NSSerg

985 — 13.07.18 — 20:13

(983) у нас каждый день несколько Guid ( а не uuid) становятся неактуальными.

  

spectre1978

986 — 13.07.18 — 20:22

(985) Т.е. вы уверены что используете GUID в запросе, но получаете ошибку неактуальной версии? Тогда, возможно, в цепочке вообще нет актуальных, т.е. номенклатура «удалена» хозсубъектом который ее завел.

  

spectre1978

987 — 13.07.18 — 20:24

И надо проверить (981) — если вдруг вышло так что указали и GUID и UUID, то используется UUID

  

Символ

988 — 13.07.18 — 21:19

  

ProxyInspector

989 — 13.07.18 — 22:09

(988) У нас уже нет APLM0012. Эта ошибка на 80% проблема разработчиков интеграционных решений и на 20% Меркурия.

  

Garykom

990 — 13.07.18 — 22:21

(988) Понятно, скоро знакомые колбасники с УТ11 начнут доставать по интеграции.

  

spectre1978

991 — 13.07.18 — 22:24

(989) по-моему, все в точности наоборот. Проблемы с перегрузками связана с тем, что изначально разработчики меркурия сделали сверхтяжелые запросы вроде получения всех ветеринарок или всех партий практически без фильтрации или с минимальной. И когда все разработчики начали это себе выкачивать ввиду того, что у них просто не было других вариантов — все вполне ожидаемо прилегло отдохнуть. Лично мне это было очевидно еще в 2016 году, что так оно и будет.

  

spectre1978

992 — 13.07.18 — 22:27

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

  

Символ

993 — 13.07.18 — 22:53

(989) Как вы решили вопрос с получением входящих документов без запросов списков?

  

ProxyInspector

994 — 14.07.18 — 08:20

  

spectre1978

995 — 14.07.18 — 08:51

(994) Ну хорошо, обошли. А вы сами как считаете, ожидания не в миллисекундах, а в десятках секунд для продуктивной системы уровня не много не мало федеральной — это вообще как? Я тут даже слово «нормально» не употребляю, потому что по-моему, это вообще за гранью добра и зла. И кто в этом виноват, интеграторы?

  

ProxyInspector

996 — 15.07.18 — 21:56

  

ProxyInspector

997 — 15.07.18 — 21:58

Не случайно же на совещании по итогам первой недели работы был сделан вывод, что если Меркурий не висит мертво, то работать можно.

  

ProxyInspector

998 — 15.07.18 — 22:05

  

NSSerg

999 — 15.07.18 — 22:49

(998) у нас после отмены молочки осталось 10000 ВСД транспортных в сутки, по бизнес-процессу они должны выписываться за полтора часа. То есть это нормально, что внедрение электронной сертификации взамен бумажной ухудшило процессы у дистрибьютеров? Я так не думаю. ИМХО это неудовлетворительно.

  

NSSerg

1000 — 15.07.18 — 22:50

(999) есно исходящих