код отправлен в клиентское приложение или раздел на сайте
Инструкция как перейти на новый портал Wildberries
Навигация по статье
Не работает старая версия портала Wildberries
Вход на портал Wildberries без логина и пароля
И так, первое и самое важное — вход на него осуществляется через номер телефона.
Если к личному кабинету НЕ привязан номер телефона, нужно связать свой личный кабинет с ним.
Инструкция:
Как это сделать:
1. Переходите по ссылке на новый портал: https://suppliers-portal.wildberries.ru/
2. Регистрируетесь:
Для осуществления входа другими сотрудниками компании, можно добавить дополнительных пользователей в разделе «Профиль пользователя».
3. В разделе «Профиль пользователя» введите логин и пароль со старого аккаунта. Нажимаете войти.
Инструкция как добавить пользователя в Wildberries:
Если ничего не помогает — актуально до 1 апреля 2021 года
Самая частая причина не возможности перейти на новый аккаунт — это проблема первого пользователя.
Для решения её недавно Wildberries запустил инструмент по переходу, цитируем письмо от WB:
Уважаемые продавцы!
Напоминаем, что наш портал переходит на новую версию. Если вы столкнулись с трудностями входа, например:
-Не помните номер телефона, который привязан к аккаунту
-К аккаунту привязан номер телефона сотрудника, который больше у вас не работает
В таком случае вам необходимо сменить ГЛАВНЫЙ номер телефона.
Для этого напишите нам на почту: PhoneChange@wildberries.ru.
Письмо должно быть оформлено строго в следующем виде:
В ТЕМЕ письма укажите свой ИНН.
В ТЕЛЕ письма должно быть:
ИНН
Номер, который хотите сделать ГЛАВНЫМ
Заявление с печатью, если у вас организация. Заявление с подписью, если печать у вас отсутсвует.
Фото гендиректора\Юр. лица с паспортом в одной руке и заявлением в другой.
Фото должно быть качественным, на нем должно быть четко видно ваше лицо и все документы.
Если один из этих документов будет нечитабелен, обращение не будет рассмотрено, отнеситесь к этому с должным вниманием.
Заявки принимаются в течение следующей недели: с 25 марта по 1 апреля.
Мы рассмотрим все заявления в порядке очереди и предоставим положительный, либо отрицательный ответ.
Убедительно просим не отправлять письма по несколько раз, потому что это не поможет ускорить процесс.
Код отправлен в клиентское приложение или раздел на сайте
Длинные они получаются. Сгибаем пополам и пишем мелкими буквами. Сделали одну с составом (она покороче) и со средствами ухода (согнутая пополам получается размером как с составом).
Что-то странное в новом портале. Код пришел на мой личный аккаунт в WB, по нему портал просит зарегистрировать новое юр. лицо.
На портал всегда заходил по логину и паролю.
У меня сначала такая же история была, тут важно ввести телефон который Вы писали когда рег. на WB первый раз свое Юр. лицо, я вспомнила ввела и все ок.
Есть поставщики, которые регистрировались на портале, когда ещё автоматических отчётов по продажам не было и их высылали на мыло 
Исправлено PAE1 (20.01.2021 20:06)
Есть поставщики, которые регистрировались на портале, когда ещё автоматических отчётов по продажам не было и их высылали на мыло
Исправлено PAE1 (Вчера 20:06)
Я зашёл. Тоже самое, но теперь в масштабе для слепых.
Я зашёл. Тоже самое, но теперь в масштабе для слепых.
Исправлено utr_alex (Вчера 15:29)
Добрый день.Подскажите пожалуйста, где искать пароль для входа на обновленный сайт? в окне с получением кода написано, что Код отправлен в клиентское приложение или раздел на сайте.Не могу сообразить, где его искать? Заранее спасибо.
У нас вообще самая первая поставка была 21 декабря. А 11 января уже получили счет за хранение. Почему так? Задаю вопрос в поддержку. А они мне все формулы шлют. У нас не прошло 60 дней. Почему мы платим тогда за хранение уже.
Добрый день.Подскажите пожалуйста, где искать пароль для входа на обновленный сайт? в окне с получением кода написано, что Код отправлен в клиентское приложение или раздел на сайте.Не могу сообразить, где его искать? Заранее спасибо.
И заходу в ново сайте в спецификацию — при заведении нового товара не дает выдрать в подменю предмет…
SD убрали, а куда писать? С Телеграмом я на вы 
добавлено через 1 минуту 22 секундыOSYA1,
А как с телегой общаться? на каком форуме?7
И как там вообще можно сто-то увидеть? Там по-моему мильон сообщений — кто-кому-куда пишет неизвестно. 
Перестали приходить Отчеты еженедельные. А те которые на Портале, не открываются. Как быть? )
столкнулись с проблемой, что Вайлдберриз приостановил оплаты на наш банковский счёт в банке ФК Открытие (Филиал Петровский). Во всех еженедельных отчетах указан ошибочно в реквизитах «Королевский Банк Шотландии», при этом указаны верно БИК 044030795 и номер счета.
Как я понимаю, этот шотландский банк имел данный БИК, а в 2014 году он был ликвидирован (отозвана лицензия ЦБ) и потом этот БИК был передан ФК Открытие.
Как Вайлдберриз умудряется не находить наш счет и так путать ума не приложу.
В личном кабинете по каждой недельной оплате пишут «Деятельность банка контрагента прекращена»
Все инциденты в Service Desk уже висят больше недели без движения (направлены в отдел поддержки поставщика Продажи и Развитие)
Руководство компании естественно нервничает и говорят мол пиши официальное письмо в ООО Вайлдберриз. Я предполагаю, что Вайлдберриз к нашему письму также «внимательно и оперативно» отнесется как и инцидентам в service desk и моим сообщениям в чате телеграмма, которые просто потёрли без ответа.
Что делать дальше? Есть ли смысл просто ждать и сколько времени обычно на решение такого пустякового вопроса требуется? Или нужно что-то делать, что может ускорить процесс?
Пользователь вводит код в приложении
Некоторые приложения (например, консольные или установленные на телевизорах Smart TV) не могут получить код подтверждения из URL. В этом случае пользователь должен самостоятельно получить код от Яндекс.OAuth и ввести его в приложении.
Получение токена в обмен на код, введенный пользователем:
Если на устройстве, где установлено приложение, недоступен браузер, пользователю придется перейти по нужному адресу на своем компьютере. Чтобы вводить адрес было удобнее, предоставьте пользователю QR-код или короткую ссылку.
Пользователь переходит на открывшуюся страницу, или по короткой ссылке и разрешает доступ приложению.
Яндекс.OAuth выводит код подтверждения. (Для этого в свойстве приложения Callback URL нужно указать адрес https://oauth.yandex.ru/verification_code ).
Яндекс.OAuth возвращает токен в теле ответа.
Полученный токен можно сохранить в приложении и использовать для запросов к API до истечения времени его жизни. Токен должен быть доступен только вашему приложению, поэтому не рекомендуется сохранять его в куках браузера, открытых конфигурационных файлах и т. п.
Получение кода подтверждения
Приложение должно направить пользователя на Яндекс.OAuth по следующему адресу:
Идентификатор приложения. Доступен в свойствах приложения (нажмите название приложения, чтобы открыть его свойства).
Уникальный идентификатор устройства, для которого запрашивается токен. Чтобы обеспечить уникальность, достаточно один раз сгенерировать UUID и использовать его при каждом запросе нового токена с данного устройства.
Идентификатор должен быть не короче 6 символов и не длиннее 50. Допускается использовать только печатаемые ASCII-символы (с кодами от 32 до 126).
Подробнее о токенах для отдельных устройств читайте на странице Токен для устройства.
Имя устройства, которое следует показывать пользователям. Не длиннее 100 символов.
Для мобильных устройств рекомендуется передавать имя устройства, заданное пользователем. Если такого имени нет, его можно собрать из модели устройства, названия и версии ОС и т. д.
URL, на который нужно перенаправить пользователя после того, как он разрешил или отказал приложению в доступе. По умолчанию используется первый Callback URI, указанный в настройках приложения ( Платформы → Веб-сервисы → Callback URI ).
В значении параметра допустимо указывать только те адреса, которые перечислены в настройках приложения. Если совпадение неточное, параметр игнорируется.
Явное указание аккаунта, для которого запрашивается токен. В значении параметра можно передавать логин аккаунта на Яндексе, а также адрес Яндекс.Почты или Яндекс.Почты для домена.
Параметр позволяет помочь пользователю авторизоваться на Яндексе с тем аккаунтом, к которому нужен доступ приложению. Получив параметр, Яндекс.OAuth проверяет авторизацию пользователя:
Если пользователь уже авторизован с нужным аккаунтом, Яндекс.OAuth просто запрашивает разрешение на доступ.
Если пользователь не авторизован с нужным аккаунтом, он увидит форму входа на Яндекс, в которой поле логина заполнено значением параметра. Помните, что токен не обязательно будет запрошен для указанного аккаунта: пользователь может стереть предзаполненный логин и войти с любым другим.
Если параметр указывает на несуществующий аккаунт, Яндекс.OAuth сможет только сообщить об этом пользователю. Приложению придется запрашивать токен заново.
Список необходимых приложению в данный момент прав доступа, разделенных пробелом. Права должны запрашиваться из перечня, определенного при регистрации приложения. Узнать допустимые права можно по ссылке https://oauth.yandex.ru/client/ /info, указав вместо идентификатор приложения.
Если параметры scope и optional_scope не переданы, то токен будет выдан с правами, указанными при регистрации приложения.
Параметр позволяет получить токен только с теми правами, которые нужны приложению в данный момент.
Если параметры scope и optional_scope не переданы, то токен будет выдан с правами, указанными при регистрации приложения.
Параметр можно использовать, например, если приложению нужна электронная почта для регистрации пользователя, а доступ к портрету желателен, но не обязателен.
Признак того, что у пользователя обязательно нужно запросить разрешение на доступ к аккаунту (даже если пользователь уже разрешил доступ данному приложению). Получив этот параметр, Яндекс.OAuth предложит пользователю разрешить доступ приложению и выбрать нужный аккаунт Яндекса.
Параметр полезен, например, если пользователь вошел на сайт с одним аккаунтом Яндекса и хочет переключиться на другой аккаунт. Если параметр не использовать, пользователю придется явно менять аккаунт на каком-нибудь сервисе Яндекса или отзывать токен, выданный сайту.
Строка состояния, которую Яндекс.OAuth возвращает без изменения. Максимальная допустимая длина строки — 1024 символа.
Можно использовать, например, для защиты от CSRF-атак или идентификации пользователя, для которого запрашивается токен.
Организация аутентификации по СМС по примеру Telegram/Viber/WhatsApp
Представим, что перед вами стоит задача организовать аутентификацию пользователя (в мобильном приложении, в первую очередь) так, как это сделано в Telegram/Viber/WhatsApp. А именно реализовать в API возможность осуществить следующие шаги:
Мне потребовалось некоторое количество времени, чтобы осознать, как правильно это сделать. Моя задача — поделиться наработанным с вами в надежде, что это сэкономит кому-то времени.
Я постараюсь кратко изложить выработанный подход к этому вопросу. Подразумевается, что у вас API, HTTPS и, вероятно, REST. Какой у вас там набор остальных технологий неважно. Если интересно — добро пожаловать под кат.
Мы поговорим о тех изменениях, которые следует проделать в API, о том, как реализовать одноразовые пароли на сервере, как обеспечить безопасность (в т.ч. защиту от перебора) и в какую сторону смотреть при реализации это функциональности на мобильном клиенте.
Изменения в API
В сущности требуется добавить три метода в ваше API:
1. Запросить СМС с кодом на номер, в ответ — токен для последующих действий.
Действие соответствует CREATE в CRUD.
Если всё прошло, как ожидается, возвращаем код состояния 200.
Если же нет, то есть одно разумное исключение (помимо стандартной 500 ошибки при проблемах на сервере и т.п. — некорректно указан телефон. В этом случае:
HTTP код состояния: 422 (Unprocessable Entity), в теле ответа: PHONE_NUMBER_INVALID.
2. Подтвердить токен с помощью кода из СМС.
Действие соответствует UPDATE в CRUD.
Аналогично. Если всё ок — код 200.
Если же нет, то варианты исключений:
3. Форсированная отправка кода повторно.
Аналогично. Если всё ок — код 200.
Если же нет, то варианты исключений:
Особенности реализации одноразовых паролей
Вам потребуется хранить специальный ключ для проверки СМС-кодов. Существует алгоритм TOTP, который, цитирую Википедию:
OATH-алгоритм создания одноразовых паролей для защищенной аутентификации, являющийся улучшением HOTP (HMAC-Based One-Time Password Algorithm). Является алгоритмом односторонней аутентификации — сервер удостоверяется в подлинности клиента. Главное отличие TOTP от HOTP это генерация пароля на основе времени, то есть время является параметром[1]. При этом обычно используется не точное указание времени, а текущий интервал с установленными заранее границами (например, 30 секунд).
Грубо говоря, алгоритм позволяет создать одноразовый пароль, отправить его в СМС, и проверить, что присланный пароль верен. Причём сгенерированный пароль будет работать заданное количество времени. При всём при этом не надо хранить эти бесконечные одноразовые пароли и время, когда они будут просрочены, всё это уже заложено в алгоритм и вы храните только ключ.
Пример кода на руби, чтобы было понятно о чём речь:
Алгоритм описан в стандарте RFC6238, и существует масса реализацией этого алгоритма для многих языков: для Ruby и Rails, для Python, для PHP и т.д..
Строго говоря, Telegram и компания не используют TOTP, т.к. при регистрации там, вас не ограничивают по времени 30-ю секундами. В связи с этим предлагается рассмотреть альтернативный алгоритм OTP, который выдает разные пароли, базируясь на неком счётчике, но не на времени. Встречаем, HOTP:
HOTP (HMAC-Based One-Time Password Algorithm) — алгоритм защищенной аутентификации с использованием одноразового пароля (One Time Password, OTP). Основан на HMAC (SHA-1). Является алгоритмом односторонней аутентификации, а именно: сервер производит аутентификацию клиента.
…
HOTP генерирует ключ на основе разделяемого секрета и не зависящего от времени счетчика.
HOTP описан в стандарте RFC4226 и поддерживается тем же набором библиотек, что представлен выше. Пример кода на руби:
Безопасность решения
Первое непреложное само собой разумеющееся правило: ваше API, где туда-сюда гуляют данные и, самое главное, token должно быть завернуто в SSL. Поэтому только HTTPS, никакого HTTP.
Далее, самым очевидным вектором атаки является прямой перебор. Вот что пишут в параграфе 7.3 авторы стандарта HOTP (на котором базируется TOTP) на эту тему:
Truncating the HMAC-SHA-1 value to a shorter value makes a brute force attack possible. Therefore, the authentication server needs to detect and stop brute force attacks.
We RECOMMEND setting a throttling parameter T, which defines the maximum number of possible attempts for One-Time Password validation. The validation server manages individual counters per HOTP device in order to take note of any failed attempt. We RECOMMEND T not to be too large, particularly if the resynchronization method used on the server is window-based, and the window size is large. T SHOULD be set as low as possible, while still ensuring that usability is not significantly impacted.
Another option would be to implement a delay scheme to avoid a brute force attack. After each failed attempt A, the authentication server would wait for an increased T*A number of seconds, e.g., say T = 5, then after 1 attempt, the server waits for 5 seconds, at the second failed attempt, it waits for 5*2 = 10 seconds, etc.
The delay or lockout schemes MUST be across login sessions to prevent attacks based on multiple parallel guessing techniques.
Если кратко, то от прямого перебора алгоритм априори не защищает и надо такие вещи предотвращать на уровне сервера. Авторы предлагают несколько решений:
Отслеживать число неудачных попыток ввода кода, и блокировать возможность аутентификации по превышению некоторого максимального лимита. Лимит предлагают делать настолько маленьким, насколько ещё будет комфортно пользоваться сервисом.
Мнение, что можно полагаться только на то, что код живёт ограниченное число секунд, и будет безопасно, т.к. код сбрасывается — ошибочно. Даже, если есть фиксированное ограничение на число попыток в секунду.
Посмотрим на примере. Пусть код TOTP состоит из 6 цифр — это 1000000 возможных вариантов. И пусть разрешено вводить 1 код в 1 секунду, а код живёт 30 секунд.
Шанс, что за 30 попыток в 30 секунд будет угадан код — 3/100000
0.003%. Казалось бы мало. Однако, таких 30-ти секундных окон в сутках — 2880 штук. Итого, у нас вероятность угадать код (даже несмотря на то, что он меняется) = 1 — (1 — 3/100000)^2880
8.2%. 10 дней таких попыток уже дают 57.8% успеха. 28 дней — 91% успеха.
Так что надо чётко осознавать, что необходимо реализовать хотя бы одну (а лучше обе) меры, предложенные авторами стандарта.
Не стоит забывать и о стойкости ключа. Авторы в параграфе 4 обязывают длину ключа быть не менее 128 бит, а рекомендованную длину устанавливают в 160 бит (на данный момент неатакуемая длина ключа).
R6 — The algorithm MUST use a strong shared secret. The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits.
Изменения в схеме БД
Итого, в модели (или в таблице БД, если угодно) надо хранить:
Особенности реализации мобильного приложения
В случае Android полученный токен можно хранить в SharedPreferences (почему не AccountManager), а для iOS в KeyChain. См. обсуждение на SoF.
Заключение
Вышеописанный подход позволит вам в рамках вашего стека технологий реализовать указанную задачу. Если вас есть соображения по этому подходу или альтернативные подходы, то прошу поделиться в комментариях. Аналогичная просьба, если у вас есть примеры документации к безопасным
Заметки из Зазеркалья
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Реализовано в версии 8.3.15.1489.
Мы реализовали механизм, с помощью которого вы можете выполнять двухфакторную аутентификацию пользователей информационной базы. Он позволяет запрашивать у пользователя аутентификационные данные двух разных типов. Это обеспечивает более эффективную защиту от несанкционированного проникновения в информационную базу.
Аутентификация
Применительно к системе 1С:Предприятие аутентификация – это процедура проверки логина и пароля, которые ввёл пользователь, на корректность. Эту операцию платформа может выполнять самостоятельно, либо может воспользоваться результатами аутентификации, которую выполнил другой ресурс, которому она доверяет (операционная система или аутентификация OpenID). В любом случае либо там, либо там пользователь выбирает некоторый логин и вводит пароль. Если логин и пароль корректные, платформа считает, что пользователь идентифицирован и предоставляет ему доступ к данным.
Эта привычная парадигма (логин / пароль) проста и удобна, но обладает одним концептуальным недостатком. Пароль надо помнить, для этого он должен быть коротким и простым. Но такие пароли легко взломать. Чтобы пароль было трудно взломать, он должен быть длинным и сложным. Но такие пароли запомнить непросто. По этой причине в реальности всё сводится к тому, что люди используют простые пароли, причём в разных местах одни и те же.
Двухфакторная аутентификация требует, чтобы пользователь имел два из трех возможных типов аутентификационных данных:
Смысл двухфакторной аутентификации заключается в том, что для того, чтобы куда-то попасть, пользователь должен дважды подтвердить тот факт, что он – это он, причём, разными способами. Например, ввести логин / пароль (первый фактор), а затем ввести код, присланный на его мобильный телефон (второй фактор).
Проверку первого фактора аутентификации выполняет платформа 1С:Предприятия, а для работы со вторым фактором аутентификации используется некоторый сторонний сервис, который мы будем называть провайдером.
Провайдер второго фактора аутентификации
Сценарии аутентификации
Чтобы дальнейший рассказ был более понятным, рассмотрим сразу два сценария аутентификации, которые позволяет реализовывать новый механизм.
Итак, стандартная аутентификация 1С:Предприятия (первый фактор) выглядит следующим образом:
Если второй фактор использовать не нужно, то считается, что пользователь полностью идентифицирован и может начинать работу. Это привычный сценарий аутентификации, который существует в платформе сейчас.
А вот если для этого пользователя нужно использовать второй фактор, то дальше возможны два новых сценария использования второго фактора аутентификации.
Простой провайдер
Этот сценарий можно использовать для «простых» провайдеров второго фактора, которые могут только передать фиксированное сообщение пользователю (например, с помощью СМС сообщения на номер телефона). В этом сценарии платформа (сервер) сама генерирует код второго фактора и полностью формирует сообщение, которое провайдер должен передать пользователю. Провайдер только передает сообщение пользователю, а платформа ожидает, когда пользователь введёт код второго фактора в окно дополнительной аутентификации.
«Умный» провайдер
Этот сценарий можно использовать для «умных» провайдеров второго фактора. Для таких провайдеров, которые, например, сами генерируют секретный код, сообщение, сами умеют информировать пользователя и проверять его данные. Предполагается, что такой провайдер заранее имеет информацию о пользователе, которая ему необходима (например, от разработчика или администратора прикладного решения). Провайдер самостоятельно выполняет аутентификацию второго фактора, а платформа ожидает сигнала от пользователя, чтобы запросить у провайдера результат этой аутентификации.
Пользователи и провайдеры
То, у какого провайдера и каким образом выполнять аутентификацию второго фактора, определяется для каждого пользователя отдельно.
В результате, например, шаблон для простого провайдера, отправляющего СМС, вы можете сформировать, задав только один запрос – запрос для аутентификации. В этом запросе будут использованы два параметра – host (адрес провайдера) и secret (код второго фактора, который сформирует платформа):
Шаблон «умного» провайдера будет содержать уже два запроса (просьба выполнить аутентификацию и запрос результатов аутентификации):
После того, как вы сохранили один или несколько шаблонов для провайдеров, вы можете каждому пользователю назначить определенный шаблон и набор значений для параметров, которые должны подставляться в этот шаблон.
Например, для пользователя, который будет использовать «простого» провайдера вы можете записать единственный параметр – адрес, на который будет отправляться HTTP-запрос (host):
А для пользователя, который будет использовать «умного» провайдера, параметров понадобится больше:
Обратите внимание, что каждому пользователю можно задать не один «набор» настроек, а несколько (массив). Свойство ОбработкаНастроекВторогоФактораАутентификации позволяет применять их по очереди в том случае, если исполнение текущего HTTP-запроса закончилось ошибкой. Например, провайдер не работает, тогда можно попробовать другого провайдера, который умеет выполнять аналогичные действия (другой набор настроек).
Журнал регистрации
Для всех новых сценариев аутентификации мы добавили в журнал регистрации новые события и новые поля некоторым старым событиям. Поэтому вы сможете контролировать не только сами процессы аутентификации, но и связанные с ними действия: изменение шаблонов второго фактора аутентификации, а также изменение настроек пользователей, связанных с двухфакторной аутентификацией.