(26)Начнем с того что тестовый сервер Меркурия – это не demo-mercury.vetrf.ru/hs, а t2-mercury.vetrf.ru. Уже здесь пользователь потратит час времени на то чтобы понять, что он не сможет работать на тестовом. Только на демо-сервере. В комментариях, причем, писали, что тестовый – это тестовый, а демо – это демо: надо бы привести в соответствие или хотя бы сделать чтоб было понятно. Явный косяк в формулировке и ныне там.
Дальше, дамы и господа, начинается лютая жесть:
Все ведь в курсе что у Меркурия есть официальный API? Так вот, на него положили. Тут почти всё через WinHttpRequest (Прикидываемся браузером и парсим ответы. Теперь задаемся вопросом: когда мы хотим смену верстки получить? Наверное, в пятницу вечером, когда будет отгрузка на пол лимона чтобы всем было интереснее). Надо бы разрабам меркурия показать эту жесть. Не исключаю вариант их физического противодействия такому решению. Вообще, сложно даже представить с какими проблемами можно столкнуться, если выбрать штатным средством – недокументированное использование Меркурия.
Раз работа идет через «псевдо-веб», то мы не сможем увидеть ни одного GUID. Отсюда сразу вытекает невозможность поработать с торговыми сетями: Например, у Магнита на каждый РЦ десятки дублей, правильный можно определить только по GUID который он прислал (так почти с каждой сетью). Еще пример: Лента требует согласовать с ней GUID 4 уровня – не имея их, поработать с Лентой не получится. И раз уж заговорили про GUIDы: сопоставления без GUIDов сделать не получится (не только номенклатура, но и другие сущности). Добавлю, что правильное сопоставление номенклатуры – это целая подсистема, которой, конечно же, нет.
Из того что есть по API – это несколько реквизитов ввода учетки и поиск ХС – всё. (После ввода учетки API, нет проверки верная она или нет. Если ошибиться и ввести неверную, то косяк, о который пользователь снова расшибет голову на час, случится позже. Кстати, не взлетит на 8.3.6 и младше т.к. сразу упадем на вычитывании wsdl. И сразу про wsdl – все время вычитывать её напрямую из меркурианского релиз-кандидата – апогей архитектурной мысли)
Не смог найти инструменты интеграции и кастомизации. Видимо надо будет всё писать самостоятельно. Скриншот с пояснениями что «можно сопоставить что угодно с чем угодно» + регистр под это дело – этого мало. Нет заполнения документов 1С. Нет извлечения данных из 1С. Нет коэффициентов пересчета номенклатуры и еще очень много чего нет. Правда, в названии и нет слова «интеграция», есть слово «обмен».
Повсеместно таблицы форм названы «Таблица1» или «Таблица11» + по классике «сопли» от конструкторов.
Справки как таковой нет, вернее она технически есть, но не думаю, что те 188 строк хелпа (с учетом пустых строк-разделителей) и без картинок можно назвать справкой, а тем более подробной.
Не работает регионализация.
Не нашел лаб. исследований.
Нет ничего из требований сетей (Существуют правила оформления ВСД, которые можно было бы обработать на стороне получателя). Почитайте, например, что сети хотят видеть в упаковках-маркировках (у Дикси, например, неплохо сформулировано) или в поле productItem.
Совсем нет разделения прав и контроля за действиями оператора (он легко что-то перепутает, забудет, навредит).
Нет нормального механизма валидации, который бы проверял транзакции и помогал пользователю.
Не являясь IT-партнером Россельхознадзора, разработчик не несет никакой ответственности за свое решение. Также не имеет возможность оперативно получать от разработчиков Меркурия ответы на свои многочисленные багрепорты (если они не многочисленные – значит поле с граблями еще впереди). Наверное, этим и объясняется отсутствие кода для работы по API 2.0.
2.
a30v
Сейчас в теме
4.
djek88
Сейчас в теме
(2)
Подскажите как задать?
образец текста напишите плиз
5.
a30v
Сейчас в теме
3.
SyachinS
Сейчас в теме
В настройках веб сервера разрешить анонимную аутентификацию.
6.
insurgut
Сейчас в теме
Если настроили веб-сервер на анонимную авторизацию, а он так и выдает ошибку авторизации после публикации базы, то проверьте, в окне публикации базы из конфигуратора – снята ли там галочка “Использовать аутентификацию операционной системы”. Эта галочка должна быть снята (по крайней мере если не используется AD).
7.
denxxxden
Сейчас в теме
Все равно при открытии в браузере выдает:
Ошибка HTTP 401.5 — Unauthorized
По URL-адресу, куда надо попасть, установлено приложение ISAPI или CGI, выполняющее проверку учетных данных пользователя до начала обработки данных. Данное приложение не может проверить ваши учетные данные.
8.
Unk92
Сейчас в теме
9.
2C_prog
Сейчас в теме
Ветис уже скоро. А что-то вокруг тишина. В программах даже что-то появилось, а на ИТС ни одной инструкции. Все ждут? или может кто-то что-нибудь делает для подготовки?
у нас какие-то другие проблемы – не доходит даже до получения APLM – через раз отказывает в http авторизации с 401 ошибкой – как в (837) писал. Никто больше не сталкивается?
может это у нас проблема такая? (через SOAP GUI тоже самое) – правда это только по справочникам (как минимум на ХС и на единицах измерения). У нас просто часто по ходу получения данных из мерка запросы к справочникам на обновления
(901) 401 не видел, но вообще HTTP ошибки бывают. 502 чаще всего.
Я не уверен, но похоже что если в getProductItemByUuidRequest
Подставить реальный GUID товара, то получаем http ответ не 200, а 500.
error code=”20022″ В реестре РСХН не найдено подходящих наименований продукции.
В моем случае вместо UUID подставляется GUID товара с active=false
У нас бывает что вместо GUID поставщик присылает UUID.
Поэтому если запрос на GUID выдал что такого нет, то пробуем проверить не UUID ли это.
По GUID функция вернула что такого товара нет (из-за active=false), а запрос getProductItemByUuidRequest выдает ошибку 500.
Это уже просто жесть.
А если к GUID добавить еще знак, например я дописал в конец “3”, то вместо того чтоб дать нормальный ответ, опять падает с HTTP ответом 500
string value
‘57796bf2-ea12-47f4-b3dc-b54f3af1009f3’
does not match pattern for UUID in namespace
Походу у них действительно сломался метод. Теперь если UUID в базе есть, то отдает всё по формату, с кодом ответа 200, если UUID нет, то получаем код ответа 500, и внутреннюю ошибку сервера.
Транспортная ВСД. Не знаю есть она или нет, но была выписана 02/07, и был получен GUID ВСД.
Сейчас при попытке получить ВСД по тикету выдает HTTP ответ 500.
Получается я должен и при HTTP 500 обрабатывать полученную XML?
Они что-ли все старые тикеты порезали в базе?
(909) Как можно перезапросить?
У тебя при создании транспортной ВСД дается тикет.
Потом по тикету ты получешь GUID ВСД.
Если тикет удален, как ты теперь ссылку на ВСД получишь? Еще одну ВСД выписать?
(910) я постоянно мониторю ответы по тикетам и записываю данные сразу как ответ положительный, после чего тикет мне не нужен.
Я бы с логов поднял обработкой. Но я их стер. 🙁
Не велика конечно потеря, но неплохо было бы где-нибудь получить полную документацию, в каких случаях HTTP ответ 500, в каких 200. Что хранится на сервере и сколько времени, что уничтожается и т.д.
По уму ошибки 500 быть не должно. Ошибка 500 – то это их внутренняя ошибка.
(911) А у меня получает номер ВСД в момент печати по тикету, и нигде он не сохраняется.
Конечно допишу чтоб сохраняла, но честно говоря я не понимаю как продукт в таком состоянии можно было запускать в продуктив в масштабах страны.
(912) так они просто xml валидируют, поэтому (905) и не проходит
(914) Если дать uuid по формату, но которого нет в базе – то тоже внутренняя ошибка. Хотя это ненормально.
Должна же быть проверка, есть ли uuid в базе, и она не должна падать с ошибкой. А код ответа http 500 – это по сути и есть падение.
(915) тут согласен
(912) ошибка 500 это ошибка веб-сервера, которая не определена явно другими 5ХХ ошибками. Похоже что они пихнули туда результаты валидации XML, который им приходит в SOAP-пакетах. Собственно, я не вижу причин почему так делать нельзя.
(917) Потому что так делать не принято.
Это соответствует их описанию, но так не делают.
(913) я сохраняю UUIDы ВСД. Привязываю их к накладной. Это статическая штука, я думаю что они будут храниться по крайней мере до тех пор, пока существует партия. Что касаемо тикетов – то это та фигня, которая отдается после submitApplicationRequest? Я правильно понял? Тогда я бы не рассчитывал на то что это будет доступно долго.
(919) Теперь и я сохраняю. А все старые похерены.
как думается мне, их нужно передавать в некое фоновое задание, которое будет немедленно добиваться по ним ответа. Как только ответ есть – данные записываются в базу, тикет уничтожается. Т.е. есть очередь тикетов, в хвост пристраиваются новые, а голова постоянно очищается путем получения ответов. Как-то так. При завершении программы юзер должен дожидаться чтобы все тикеты были отработаны, иначе ругаться громко и матом – ибо по факту это будет означать что результаты выполнения всех необработанных заявок будут утеряны.
это я про тикеты. А UUIDы я сохранял изначально. Помимо UUIDов, я подбираю из веток еще кое-какое барахлишко для локальной печати веток (без участия Меркурия).
(921) Зачем? У меня и так всё отлично работает. Я их в любом случае получаю в момент печати. Без него же не распечатать. Теперь как получил буду сохранять.
(922) И тикеты в любом случае нужно сохранять, если ассинхрон как у меня. Конечно сохраняются.
Короче в итоге вернул обратно – код 500 у меня опять равносилен либо пустому запросу, либо REJECTED. Даже не разбираю его. Что конечно-же неправильно.
По (925) вопрос снят, разобрался
(927) Интересная встреча. Но это только десяток крупнейших производителей и сетей.Каждый из которых вбухал по 100 млн. руб и имеет процент гашения на уровне 30% – 70%. А каково остальным сотням тысяч предприятий. И что будет с системой Меркурий, когда эти предприятия начнут активно работать.
Лично у нас распределительный центр на 50 магазинов. На сегодняшний день мы получаем только на 10% продукции входящие ВСД, и изготовляем 0% исходящих ВСД
(927) Магнит в касте избранных? Похоже из 80 серверов – половина у них. Имхо, нечестная конкуренция и попытка задавить частные сети. Власов всех затыкал, когда разговор заходил не в то русло, а им минут 10 дал поболтать совсем не по-делу.
И да, все кругом идиоты, а у них все шикарно без ошибок.
(931) Вот что животворящий выкуп акций ВТБ делает! 🙂
(931) вы думаете они х5 задавят.
Я не понял. оборудование меркурия на площадках магнита или на их серверах крутится? или все это магнит задумал
(933) там странная история. Вы статистику смотрели? Магнит обрабатывает четверть всего трафика ВСД. А Х5 – несколько процентов.
(934) обрабатывает или использует ВСД?
(936) Элементарно. Это их распредцентры генерят.
Поставщики отдают товар не по магазинам а на РЦ, у х5 РЦ меньший траффик видимо.
а ВСД формировать то надо от РЦ в магазин. т.к. перевозка хоть и без смены владельца.
(937) Видимо, у x5 прямых поставок в магазины больше, чем у Магнита.
(937) да, точняк. Но тогда тем более интересно, почему такое различие между Х5 и Тандером. Тандер раньше начал, да. Они требовали ЭВСД еще в середине прошлого года.
(938) Не исключено. Х5 загонять своих поставщиков на РЦ в обязательном порядке стали не так давно как Тандер.
(938) видимо
(939) судя по моим знакомым. тандер стал еще с июня требовать ВСД.
2. с чего. не все возможно в РЦ загнать. У Магнита кстати логистика построена видимо через РЦ. более. чтобы не отвлекать народ в магазинах на поставки. да и поставка на РЦ всегда цена ниже. чем поставщик развозит по магазинам. и у Тандера остается больше бабла.
У Магнита может быть куча распределительных центров, куча магазинов, все от разных юр.лиц. При этом гасить ВСД магазины не могут чисто физически. Получается ситуация как у нас.
Распределительный склад + 50 магазинов должны генерить 10 млн. ВСД в год. При количестве номенклатуры 1000 позиций.
А у сетей и магазинов и позиций поболее. Поэтому для крупных сетей количество ВСД может достигать мрлд. в год.
Не завидую я им
(941) если прибавить еще алкоголь. то Ит трафик у магазина огого
(933) Я думаю, либо они часть серверов сами купили и поставили Россельхозу под Меркурий под свои нужды, либо пришла директива выделить им сервера чисто под них. Иначе ситуация когда никто не может получить ВСД, а у них все хорошо – выглядит странной.
(943) ну да. Причем если Галицкий еще мог заупрямиться, то теперь-то там зеленая улица. Скажут – сделают.
Либо они сами не понимают в какой ж-пе находятся.
(943) ну это да. что-то тут явно не так
для компаний у кого РЦ тут ве проще. Им не надо в одночасье выплевывать всд в магазины. главное чтобы в РЦ пришло все с ВДС. А далее они оформят когда будет свободно..
Это если поставщик в магазин приводит должно быть уже ВСД. а для своих то поставок такой спешки явно нет. и авто едет из РЦ порой сутки. всегда есть время.
А вот компании которые не на РЦ везут из за того. чо свой сбыт и до РЦ дальше чем до магазина. вот тут уже засада
(947) Больше всех производители страдают, как собственно обычно.
(948) производителю до РЦ тоже не проблема сделать. хоть в ручную.
а вот если у производителя свой распределенный сбыт. тут вот уже проблема
(949) Между площадками при производстве ничего не перевезешь толком. Через дорогу перевезти – тоже нужно ВСД выписать.
(950) знаю. у нас 3 завода 2-4 км друг от друга. и все 3 находятся в разных раонных ветслужбах.
У меня сейчас Ветис умер. При этом умер он на функции getProductByGuid. Это основополагающая функция. Если она умирает, тогда останавливается весь Ветис. При этом умирал он медленно. Сначала умерла функция getProductByGuid, а через несколько минут – Ветис
(952) У меня если продукт не может получить по guid-у (а проверяет active обязательно, ибо выводят из базы продукцию), тогда инвентаризация, и отгрузка по ТНВЭД (третьему уровню). Ничего не останавливается.
И, кстати, только что делал большую ВСД на 41 позицию – всё нормально, ушло с гуидами. Значит getProductByGuid работает.
Сейчас массово
<apl:error code=”APLM0017″ xmlns:apl=”http://api.vetrf.ru/schema/cdm/application”>An unexpected error has occurred while processing target service response.</apl:error>
Как на неё реагировать? Это в ответ на запрос по тикету.
По поводу getProductByGuid ошибочка у меня вышла.
Оказывается что
Родитель второго уровня это GetProductByGuid
Родитель третьего уровня это это GetSubProductByGuid
И если по GUID элемент не найден, тогда возвращается код ошибки 500 – сервис не доступен.
(957) Да. Причем ночью опять всё штатно отработало.
Буду писать список кодов при которых нужно пытаться перевыписать ВСД (ошибка со стороны меркурия), и список с которыми нужно разбираться.
Часть накладных не уехало, потому что по непонятной причине не дало выписать от имени уполномоченного сотрудника, с ошибкой
“MERC02386” Данная транзакция не может быть оформлена, так как роль пользователя не позволяет оформлять ВСД
ПО ТНВЭД
d99981f8-b4a3-4d13-867c-01ed252edb1b
желированные продукты из мяса и субпродуктов (1602)
Это продукция прошедшая термообработку, из 646 приказа.
(960) Назначение какое указали?
(961) Как и все остальные. Реализация в пищу людям
(960) Это была ошибка в меркурии, вроде по нашему обращению поправили. Действительно под этим ТНВЭД уполномоченным не давала выписывать. Завтра проверим.
Что-то ветка затихла.
Насчет APLM20001 – битые площадки.
Вывели полный список – у нас их сотни. И оказалось что проблема решаемая, сотрудником РСХН с достаточными правами. Чтоб решить проблему нужно изменить что-либо в площадке и пересохранить. GUID площадки при этом не меняется. Единственная проблема в правах.
Назначить обновление на пятницу 13-ое это сильно.
https://www.vetrf.ru/vetrf/news/27290.html
Всем причастным к этой загашочной планете рекомендую в выходные не пить, из города не уезжать и быть на связи.
Так хотелось отдохнуть, а придется вздрагивать от каждого звонка. 146% что всё ляжет.
(966) та ладно, с чего такой пессимизм. Оно уже не раз обновлялось и не десять, а ложилось в редких случаях
вот про лабораторные исследования надо уточнить. По-моему, я при запросе партий это дело проверяю, но я работаю через getStockEntryList, не через Changes. Так что меня коснуться не должно
Кстати, рекомендую почитать список обновлений уважаемому NSSerg. Там первое обновление как раз по его душу – появилась возможность указывать иностранное предприятие-поставщика без указания его GUID для входящей партии.
(965) У нас на такие площадки в день сотни ВСД, выписать на них невозможно в принципе. Эти площадки не выбираются в меркурии, через API на них не сделать ни регионализацию, ни транспортную ВСД.
(969) Мы закачали справочник иностранных площадок, и во всех товарах проставили площадку производителя. Хотя ИМХО почему бы этот справочник просто не выложить? Почему РСХН его не выкладывает? Там по каждой стране всего лишь несколько сотен площадок. Все наши площадки там есть.
Есть ли в Меркурии функция получения описания ошибки по ее коду через API
А то посылаешь запрос на гашение, а тебе в ответ
REJECTED ERR MERC13286
В ВИКИ есть http://help.vetrf.ru/wiki/IncomingOperation
описание. Но хочется как то более цивильно
(971) нет. У меня тот же вопрос, но походу нет, у тебя вместе с ошибкой возвращается её текстовое описание.
(971) так вроде в BusinessError возвращаются текстовые описания. Или у вас провайдер, а не API?
У меня в IncomingOperation – оформление входящей партии возвращает только КодОшибки.
Кто нибудь сталкивался с такой ошибкой. MERC14023 В сведениях о принимаемой партии указана устаревшая версии записи вида продукции наименовании продукции.
Что то я не вижу способа обойти эту ошибку по API
В справке написано “В запросе для номенклатуры продукции указан идентификатор устаревшей версии записи реестра РСХН” и как это перевести на русский язык?
(975) это значит продукция выведена из реестра РСХН?
Через WEB Я погасил эту ВСД. Где-то проскакивало, что в Меркурии утверждают, что такую ВСД можно погасить только через WEB интерфейс
Через API не смог, хотя продукция полностью обновлена.
(975)(976)(977) скорее всего это означает, что в запросе для продукции указали UUID продукции, а не GUID, и этот UUID является идентификатором непоследней версии продукции. Я не Ванга, но думаю, что произошло следующее: ваши контрики выписали ВСД, используя последний на тот момент UUID продукции. А потом, пока ВСД летел к вам, что-то подправили в справочнике для этой номенклатуры – название там поменяли или еще чего, может, просто ОК нажали. В результате для соответствующего GUID номенклатуры образовалась новая последняя версия с новым UUID, а тот UUID, который был в ВСД – стал неактуальным. Чтобы это полечить, наверно, нужно при приемке либо сменить UUID на последний, либо очистить его и заполнить GUID.
Кстати! Ща скажу важную вещь, на которую напоролся. Если для какой-то версионной сущности в запросе заполнен и GUID, и UUID, приоритет у UUID! Так что если не хотите ловить ошибки с устаревшей версией, не пользуйтесь UUID без крайней необходимости.
В конфигурацию Розница (2.2.9.19) добавили работу с Меркурием, кто уже тестил?
Конечно функционал только для подписчиков ИТС.
И в УТ11 не в курсе когда?
У вас ВЕТИС у НАС ВС внедряют.
Виртуальный склад.
Скоро будут следить за всеми движениями товаров (((
(983) у нас каждый день несколько Guid ( а не uuid) становятся неактуальными.
(985) Т.е. вы уверены что используете GUID в запросе, но получаете ошибку неактуальной версии? Тогда, возможно, в цепочке вообще нет актуальных, т.е. номенклатура “удалена” хозсубъектом который ее завел.
И надо проверить (981) – если вдруг вышло так что указали и GUID и UUID, то используется UUID
(982) В УТ 11 уже давно.
Вот только у меркурия пока проблемы с APLM0012
(988) У нас уже нет APLM0012. Эта ошибка на 80% проблема разработчиков интеграционных решений и на 20% Меркурия.
(988) Понятно, скоро знакомые колбасники с УТ11 начнут доставать по интеграции.
(989) по-моему, все в точности наоборот. Проблемы с перегрузками связана с тем, что изначально разработчики меркурия сделали сверхтяжелые запросы вроде получения всех ветеринарок или всех партий практически без фильтрации или с минимальной. И когда все разработчики начали это себе выкачивать ввиду того, что у них просто не было других вариантов – все вполне ожидаемо прилегло отдохнуть. Лично мне это было очевидно еще в 2016 году, что так оно и будет.
то же самое, кстати, подтвердил Власов на встрече с представителями бизнеса. И сейчас (конкретно в сегодняшнем обновлении) они уже пытаются повыкинуть из ответов часть данных, чтобы хотя бы снизить нагрузку на сеть.
(989) Как вы решили вопрос с получением входящих документов без запросов списков?
(993) Корректно сделали таймауты.
Запрос на получение списка вет сертификатов. Цикл с таймоутом 120 сек и задержкой между запросами 10 сек. Прерываемся только если COMPLETED. На все остальные ошибки не смотрим.
Получение ответа на запрос. Цикл с таймоутом 120 сек и задержкой между запросами 3 сек. Прерываемся только если COMPLETED ИЛИ REJECTED. На все остальные ошибки не смотрим.
Где то так примерно. Не могу посмотреть точно.
Проблем с получением списка сертитификатов имеем если на протяжении 120 сек не смогли отправить запрос на получение. Но это происходит когда Меркурий совсем висит.
(994) Ну хорошо, обошли. А вы сами как считаете, ожидания не в миллисекундах, а в десятках секунд для продуктивной системы уровня не много не мало федеральной – это вообще как? Я тут даже слово “нормально” не употребляю, потому что по-моему, это вообще за гранью добра и зла. И кто в этом виноват, интеграторы?
Не так страшен черт.
У нас гашение входящих ВСД 1 машины занимает 30 секунд. Не очень много. Если взять распределительный склад уровня Метро, то у них не более 1000 машин в сутки. Вполне могут работать.
Интеграционное решение должно быть нормальным.
Не случайно же на совещании по итогам первой недели работы был сделан вывод, что если Меркурий не висит мертво, то работать можно.
Мы не производители, поэтому продукцию не заводим, а получаем из входящих ВСД. Ставим только соответствие между продукцией меркурия и нашей номенклатурой.
Входящие ВСД можно получать в регламентном задании.
(998) у нас после отмены молочки осталось 10000 ВСД транспортных в сутки, по бизнес-процессу они должны выписываться за полтора часа. То есть это нормально, что внедрение электронной сертификации взамен бумажной ухудшило процессы у дистрибьютеров? Я так не думаю. ИМХО это неудовлетворительно.
(999) есно исходящих
Страница с ошибкой при обращении к 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 методов, которые вы можете использовать.
- Проверьте ваш URL.
Начнем с самого простого потенциального решения: убедитесь, что вы использовали верный URL. Это может выглядеть банально, но 401 ошибки нередко появляются, если URL-адрес был введен неправильно.
Еще один вариант: ссылка, которую вы использовали для перехода на запрашиваемую страницу, указывает на неправильный URL. К примеру, ссылка устарела, ведет на страницу, которой больше нет (и редиректов не задано).
Стоит тщательно перепроверить URL-адрес, который вы использовали. Если вы набирали адрес самостоятельно, убедитесь, что все написано безошибочно. Если вы переходили по ссылке, убедитесь в том, что она ведет на страницу, к которой вы хотите получить доступ (либо попробуйте перейти на эту страницу непосредственно через сайт).
- Почистите кэш браузера.
Кэш браузера предназначен для улучшения процесса взаимодействия с сайтами в сети за счет сокращения времени загрузки страниц. К сожалению, иногда это может вести к нежелательным последствиям.
Как мы уже говорили выше, одной из распространенных причин появления ошибки 401 являются устаревшие или неправильные данные кэша или cookies. Потому, если URL введен верно, следующий шаг – чистка кэша браузера.
В итоге вы удалите любую недействительную информацию, которая хранится локально в вашем браузере и может приводить к прерываниям процесса аутентификации. Аналогично, файлы cookie вашего браузера могут содержать аутентификационные данные, которые нужно обновить.
Если вы пользуетесь Chrome, вам нужно щелкнуть по иконке с меню в правом верхнем углу браузера и выбрать пункт Settings. В разделе «Privacy and security» нажмите «Clear browsing data:»
Далее вводим URL требуемого сайта и очищаем для него данные.
В других браузерах процесс очистки кэша и cookie может отличаться. К примеру, в Firefox нужно щелкать по иконке с библиотекой и выбирать History > Clear Recent History:
Информацию по остальным браузерам вы можете найти в поисковиках.
- Очистка DNS.
Еще один метод, который вы можете попробовать для устранения ошибки 401 – это очистка DNS. Эта причина встречается относительно редко, но стоит попробовать и такой подход, особенно если первые два ничего не дали.
Чтобы очистить DNS, перейдите в Windows к меню «Пуск» и там уже введите в строку поиска cmd. Нажмите Enter. Откроется командная строка. Далее вставьте команду ipconfig/flushdns, после чего снова нажмите Enter.
Если вы пользуетесь Mac, вы можете открыть командную строку следующим образом: Finder > Applications > Utilities > Terminal.
Введите команду sudo killall -HUP mDNSResponder и нажмите Enter. Затем вы можете обновить страницу, чтобы посмотреть, пропала ли ошибка 401 или нет.
- Деактивируйте ваши плагины
Проблема может возникать и по вине плагинов.
Некоторые плагины, особенно связанные с безопасностью, могут выдавать ошибку 401 при подозрении на вредоносную активность. Также у них могут быть проблемы с совместимостью. Потому лучше всего деактивировать все плагины и посмотреть, будет ли страница работать.
Вы можете деактивировать все плагины разом, перейдя в раздел Plugins > Installed Plugins в консоли WordPress. Выберите все плагины и в меню Bulk Actions задайте Deactivate, после чего щелкните по кнопке Apply:
После этого попробуйте перезагрузить страницу с ошибкой. Если ошибка пропала, вы можете вручную по одному активировать плагины заново, чтобы выявить виновника всех бед.
Далее вы уже можете либо удалить плагин, либо написать его разработчикам, чтобы они предоставили рабочее решение.
- Проверьте заголовок 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.