Наша совместная команда Banwar.org

Связаться с нами

  • (097) ?601-88-87
    (067) ?493-44-27
    (096) ?830-00-01

Статьи

овебмані.Ру - все про WebMoney. Login.WebMoney: авторізуемся, виводимо із тіні.

  1. Вступ
  2. Принцип роботи сервісу Login.WebMoney
  3. Встановлені
  4. Авторизація користувача на стороні Login.WebMoney
  5. отримання тікета
  6. Перевірка тікета
  7. Що ще потрібно знати
Матеріал для розробників і власників сайтів.

© Микита Сенченко

Вступ

Кількість мережевих проектів, які з'єднали свій бізнес з WebMoney, росте з дня на день. Клієнти цих проектів одночасно є користувачами WMT, і часто виникає необхідність точно їх ідентифікувати і отримувати достовірні WMID. Наприклад, обмінний пункт впроваджує бонусну програму і хоче прив'язати розмір знижки до конкретного WM-ідентифікатором (це розумно, оскільки звичайний логін, на який нараховується знижка, користувачі зможуть вільно передавати один одному, тим самим обманюючи обмінник). Інший приклад: кредитний сервіс, автоматизованих видачу WM-кредитів, бажає авторізовиваться кредиторів на своєму сайті і точно визначати їх WMID, так як це дуже важливо для зниження ризиків. А ось ще: якийсь сайт проводить розіграш подарунків серед користувачів WebMoney, для чого йому необхідно визначати і зберігати їх WM-ідентифікатори, так як WMID являтся єдиним, що однозначно ідентифікує користувача WebMoney, як номер паспорта однозначно ідентифікує людини.

Подібних прикладів можна навести безліч. Раніше для авторизації WebMoney-користувачів на своєму сайті потрібно було програмувати непростий інтерфейс X7 для входу по Keeper Classic і навіть особливим чином налаштовувати веб-сервер для входу за сертифікатом Keeper Light (Ці способи, втім, ніхто не відміняв, і так організовувати аутентифікацію на своєму сайті можна і зараз.) Не кажучи вже про те, що авторизація з допомогою системи Enum і авторизація для користувачів GSM Кіпера взагалі була недоступна для власників сайтів. Тому спеціально для спрощення даної задачі розробники WebMoney запропонували сервіс Login.WebMoney , Який всі ці проблеми вирішує і з яким ми зараз познайомимося.

Принцип роботи сервісу Login.WebMoney

Login.WebMoney працює за наступним принципом. Припустимо, ваш сайт повинен авторизувати якогось WebMoney-користувача, тобто визначити його WMID. Для цього він просто направляє його на спеціальну сторінку сервісу Login.WebMoney, де користувач і проходить авторизацію, вибираючи будь-який зручний для нього спосіб: Keeper Classic, Light, Enum або GSM Keeper. Тобто реально авторізуетесь користувача не ви, а система WebMoney. Далі Login.WebMoney генерує тікет - унікальний сесійний ключ, що складається з символів і задовольняє регулярному виразу [a-zA-Z0-9 \ $ \! \ /] {32,48}. Цей тікет передається сторінці вашого сайту разом з WMID тільки що авторизованого користувача. На ту ж сторінку перенаправляється і сам користувач. Ваш сайт, отримавши ці дані, перевіряє ще раз їх: запитує у сервера Login.WebMoney, а чи дійсно існує такий тікет і чи дійсно він відповідає такому WMID. Отримавши позитивну відповідь, ваш сайт вважає отриманий WMID достовірним. Усе!

Розглянемо тепер все це на конкретному прикладі і покажемо, як це можна запрограмувати. Нагадаємо, перед нами стоїть завдання: отримати достовірний WMID користувача і тим самим авторизувати його на своєму сайті.

Встановлені

йдемо на login.wmtransfer.com (Якщо потрібно - примусово перемикаємо мову з англійської на російську в верхньому правому куті). Тиснемо увійти авторізуемся. Натискаємо пункт меню Сайт. Тут задаємо основні параметри, а саме:

  • Назва вашого сайту або мережевого проекту (так його будуть бачити користувачі).
  • Час життя тікета (в хвилинах). Це час, протягом якого згенерований системою тікет буде актуальним, тобто про нього система буде давати відповідь, що такий тікет існує. За умовчанням встановлено 20 хвилин, але якщо немає якихось особливих обставин, через які вам потрібно буде перевіряти тікет тривалий час і багато разів, рекомендую в цілях безпеки зменшити це значення до 1-2 хвилин. Цього цілком вистачить, щоб перевірити тікет один раз.
  • Методи авторизації, які будуть доступні відвідувачам вашого сайту. Не бачу причин знімати тут якісь галочки.
  • Натискаємо кнопку [Зберегти].

    Не бачу причин знімати тут якісь галочки

    Йдемо в розділ Url сайта, натискаємо там посилання Додати і вводимо точний URL сторінки нашого сайту, яка буде відповідати за авторизацію. На цю сторінку користувач буде повертатися з сервісу Login.WebMoney, туди ж передаватиметься тікет, там же буде відбуватися і перевірка тікета. URL вводите повністю, з протоколом. Для безпеки рекомендуємо працювати по протоколу https. Тиснемо [Додати].

    URL з'явився в списку. Сервіс присвоїв йому спеціальний urlid (перша колонка), що складається з безлічі букв і цифр. Для чого він потрібен - розберемося пізніше.

    Додані URL можна редагувати (важливо: при цьому змінюється urlid!) Або видаляти. Редагування, по суті, рівнозначно видалення старого і додаванню нового URL.

    Зверніть увагу, що в список можна додавати будь-яку кількість різних URL, навіть відносяться до різних доменів, наприклад, http://site1.ru/enter.php, https://login.site2.ru/welcome/ і т.д. Всі URL рівноправні, ви зможете використовувати всі їх паралельно і одночасно. Однак, на жаль, Login.WebMoney дозволяє вказувати тільки одне ім'я сайту (інтернет-проекту) та встановлювати тільки одні налаштування (сторінка Сайт) на один ваш WMID. Таким чином, якщо ви хочете використовувати WM-авторизацію на декількох мережевих проектах - сміливо додавайте всі ці URL, але назва для них придумайте якесь одне, спільне.

    Авторизація користувача на стороні Login.WebMoney

    У той момент, коли вам потрібно авторизувати користувача, ви відправляєте його за адресою https://login.wmtransfer.com/GateKeeper.aspx?RID= urlid, де разом urlid підставте значення urlid, видане системою вашому URL. Скажімо, для нашого прикладу: https://login.wmtransfer.com/GateKeeper.aspx?RID=31055ee4-7ebc-410e-acab-9a2c00332e01 . Тут 31055ee4-7ebc-410E-acab-9a2c00332e01 - це urlid для URL http://owebmoney.ru/files/wmlogin/login.php, доданого нами в систему (див. Скріншот вище). Трохи пізніше, після того як Login.WebMoney авторизує користувача, він відправить тікет і WMID користувача (а також самого користувача) саме на цю адресу URL. Але до цього ми підійдемо через пару хвилин.

    До речі, сайт Login.WebMoney намагається визначити рідна мова користувача і правильно "підсунути" йому свою російську або англійську версію. Однак, іноді це не спрацьовує, тому в тій же адресному рядку ви можете примусово передавати параметр lang для того, щоб вказати сайту Login.WebMoney, яка мова використовувати. lang = ru-RU вкаже, що потрібно відобразити російську версію, а lang = en-US - англійську. приклад: https://login.wmtransfer.com/GateKeeper.aspx?RID=31055ee4-7ebc-410e-acab-9a2c00332e01&lang=ru-RU

    Потрапивши на сайт Login.WebMoney, ваш користувач бачить наступне:

    Тут він вибирає той метод авторизації, який йому підходить, але тільки з числа тих методів, які ви дозволили в налаштуваннях. Зверніть увагу, що вгорі авторизаційної форми юзер бачить назву вашого сайту (ми ставили його в настройках) і URL, куди він потрапить після авторизації.

    отримання тікета

    Система авторизує користувача, тобто визначає його WMID. Відразу після цього вона перенаправляє його на ваш URL, асоційований з тим urlid, за яким користувач тільки що потрапив на сайт Login.WebMoney. На той же URL система передає наступні параметри методом POST:

    • WmLogin_AuthType - спосіб аутентифікації. значення:
      KeeperClassic - аутентифікація через WebMoney Keeper Classic
      KeeperLight - аутентифікація через сертифікат WebMoney Keeper Light
      Enum - аутентифікація через сервіс Enum
      Telepat - аутентифікація через сервіс telepat
    • WmLogin_Created - UTC час створення авторизационного тікет в форматі dd.mm.yyyy hh: mm: ss
    • WmLogin_Expires - UTC час закінчення терміну дії тікет в форматі dd.mm.yyyy hh: mm: ss
    • WmLogin_LastAccess - UTC час останнього звернення до тікету в форматі dd.mm.yyyy hh: mm: ss
    • WmLogin_Ticket - авторизаційний тікет. Чи задовольняє регулярному виразу [a-zA-Z0-9 \ $ \! \ /] {32,48}
    • WmLogin_UrlID - urlid повернення, на який здійснюється POST
    • WmLogin_UserAddress - IP адреса користувача
    • WmLogin_WMID - WMID користувача

    Як бачимо, ми отримуємо від системи багато інформації, але в класичному випадку (і в нашому прикладі теж) не вся ця інформація нам знадобиться. Найважливіше тут - параметри WmLogin_Ticket і WmLogin_WMID. Перший містить тікет (нагадаємо, тікет - це унікальний неповторяющийся сесійну пароль), а другий містить WMID користувача.

    Зрозуміло, що будь-який зловмисник може зімітувати відправку на ваш URL такої форми з вигаданим тікети і WMID. Тому ви не повинні приймати все за чисту монету і повинні обов'язково перевіряти достовірність одержуваних тікетів. Але цим ми займемося трохи пізніше, а поки напишемо простий код на PHP, який буде за формальними ознаками відсікати хибні виклики, що надходять на наш URL, вже на цьому етапі.

    // !!!!!! У наступному рядку вкажіть urlid, відповідний ВАШОМУ URL $ urlid = "31055ee4-7ebc-410E-acab-9a2c00332e01"; $ Testticket = preg_match ( '/ ^ [a-zA-Z0-9 \ $ \! \ /] {32,48} $ / i', $ _POST [ 'WmLogin_Ticket']); if ($ _ POST [ 'WmLogin_UrlID'] == $ urlid && $ testticket == 1) {echo "=== Тикет отриманий успішно ===
    "; // Продовжуємо виконання скрипта // ...} else echo" === Помилка при отриманні тікета === ";

    Тут ми: 1) перевірили, що параметр WmLogin_UrlID, отриманий нашим скриптом, дійсно збігається з тим urlid, який видала нам система (див. Третій скріншот в статті); 2) переконалися, що тікет має правильний формат. Якщо перевірки пройдено успішно - продовжуємо виконання скрипта; якщо немає, то виводимо повідомлення про помилку.

    Перевірка тікета

    Як ми вже говорили, після отримання тікета потрібно обов'язково перевірити його справжність. Тільки коли ми переконаємося, що тікет справжній, ми можемо бути на 100% впевненими, що вірний і WMID користувача, яку ми здобули разом з даними тікети.

    Перевіряти справжність тікета будемо в тому ж скрипті, який тільки що цей тікет і отримав. Так, швидше за все, буде і в вашому випадку. Перевірка займає 1-2 секунди, в цей час користувач буде чекати завантаження URL у браузері.

    Перевірка тікета може проводитися згідно SOAP-інтерфейсу або XML-інтерфейсу . З протоколом SOAP в PHP працювати не дуже зручно, тому скористаємося XML-інтерфейсом. Цей інтерфейс полягає в тому, що ми повинні відправити XML-запит з перевіряється тікети і рядом інших параметрів на URL https://login.wmtransfer.com/ws/authorize.xiface і отримати від системи XML-відповідь з результатами перевірки.

    Запит повинен мати такий вигляд:

    Що повинно передаватися в цих параметрах:

    • siteHolder - ваш WMID (тобто WMID власника сайту, зареєстрованого в Login.WebMoney);
    • user - WMID користувача (отриманий раніше від Login.WebMoney разом з тікети);
    • ticket - перевіряється тікет;
    • urlId - urlid, за яким був авторизований користувач;
    • authType - спосіб аутентифікації (отриманий раніше від Login.WebMoney разом з тікети);
    • userAddress - IP-адреса користувача (отриманий раніше від Login.WebMoney разом з тікети).

    Формуємо XML-запит:

    $ Xml = "$ mywmid". $ _ POST [ 'WmLogin_WMID']. "". $ _ POST [ 'WmLogin_Ticket']. "". $ Urlid. "". $ _ POST [ 'WmLogin_AuthType']. "". $ _ POST [ 'WmLogin_UserAddress']. "";

    Запит потрібно відправляти методом POST, тому будемо використовувати бібліотеку libcurl (CURL) . Як правило, вона включена в збірку PHP навіть на недорогих віртуальних хостингах. Перевірити, чи дозволені CURL на вашому сервері, можна за допомогою функції phpinfo () або так: echo function_exists ( "curl_init") ;.

    // Відправляємо запит і отримуємо відповідь $ resxml = _GetAnswer ($ xml);

    Напишемо функцію _GetAnswer (), яка буде отримувати на вхід наш XML-пакет із запитом, відправляти його на сервер Login.WebMoney, використовуючи CURL, і отримувати відповідь, віддаючи цей відповідь на виході.

    function _GetAnswer ($ xml) {global $ CertPath; // ініціалізувавши сеанс CURL $ ch = curl_init ( "https://login.wmtransfer.com/ws/authorize.xiface"); // У висновку CURL http-заголовки не потрібні curl_setopt ($ ch, CURLOPT_HEADER, 0); // Повертати результат, а не виводити його в браузер curl_setopt ($ ch, CURLOPT_RETURNTRANSFER, 1); // Метод http-запиту - POST curl_setopt ($ ch, CURLOPT_POST, 1); // Що передаємо? curl_setopt ($ ch, CURLOPT_POSTFIELDS, $ xml); // Задаємо кореневий сертифікат для перевірки curl_setopt ($ ch, CURLOPT_CAINFO, $ CertPath); curl_setopt ($ ch, CURLOPT_SSL_VERIFYPEER, TRUE); // Виконуємо запит, відповідь поміщаємо в змінну $ result; $ Result = curl_exec ($ ch); if (curl_errno ($ ch)) echo "Curl Error number =" .curl_errno ($ ch). ", Error desc =" .curl_error ($ ch). "
    "; Curl_close ($ ch); return $ result;}

    Помістимо цю функцію в самий кінець нашого поки що недописаний скрипта.

    Зверніть увагу на наступні рядки:

    curl_setopt ($ ch, CURLOPT_CAINFO, $ CertPath); curl_setopt ($ ch, CURLOPT_SSL_VERIFYPEER, TRUE);

    Щоб (з метою безпеки і захисту від DNS-атак) під час сеансу CURL міг перевірити валідність сертифіката на сервері Login.WebMoney, ми використовуємо аргументи CURLOPT_CAINFO і CURLOPT_SSL_VERIFYPEER. Для цього нам потрібно завантажити і помістити кореневий сертифікат сервера Login.WebMoney (WMunited.cer) куди-небудь на свій сервер і прописати шлях до нього (від кореня сервера) в змінній $ CertPath, яка передається аргументу CURLOPT_CAINFO.

    Також зверніть увагу, що в разі виникнення помилок при роботі CURL в функції _GetAnswer () рядок

    if (curl_errno ($ ch)) echo "Curl Error number =" .curl_errno ($ ch). ", Error desc =" .curl_error ($ ch). "
    ";

    покаже номер і опис помилки.

    Нагадаю, ми зупинилися на тому, що отримали XML-відповідь від сервера Login.WebMoney і зберегли його в змінну $ resxml. XML-відповідь має формат:

    Що означають атрибути єдиного параметра response:

    • retval - код результату перевірки тікета. 0 - якщо тікет існує, достовірний і термін його дії не закінчився.
    • sval - текстовий опис результату перевірки тікета.
    • lastAccess - UTC час останнього доступу до перевіряється тікету.
    • expires - UTC час, коли термін дії перевіряється тікета закінчиться.

    З усіх атрибутів нас цікавить тільки retval. Якщо він дорівнює 0, то перевірка тікета завершена з позитивним результатом, сам тікет достовірний і, відповідно, отриманий разом з ним WMID можна вважати підтвердженим. інші коди говорять або про помилки при перевірці тікета, або про те, що тікет не є справжнім.

    Отже, нам залишилося доповнити код нашого php-скрипта розбором XML-відповіді і отриманням значення retval. Це можна зробити абсолютно по-різному, в залежності від ваших уподобань. У PHP багато інструментів для XML-парсинга. Більш того, оскільки відповідь має дуже просту і чітку структуру, витягнути значення retval з нього можна навіть за допомогою регулярних виразів. Однак, ми в своєму прикладі скористаємося звичної для нас і простий бібліотекою SimpleXML (Підтримується тільки в PHP5, але не в PHP4):

    // Розбираємо XML-відповідь $ xmlres = simplexml_load_string ($ resxml); if (! $ xmlres) echo "Чи не отримано XML-відповідь"; $ Result = strval ($ xmlres-> attributes () -> retval); // Якщо результат не дорівнює 0 - перериваємо і видаємо помилку if ($ result! = 0) echo "Тикет помилковий :("; else {echo "Тикет вірний :) Ви авторизовані!
    "; Echo" Ваш WMID - ". $ _ POST [ 'WmLogin_WMID']."
    "; // Виконуємо необхідні дії, // наприклад, авторізуемся користувача, починаємо сесію і т.д. // ...}

    А це, власне, і все. На даний момент ви отримали достовірний WMID користувача, а сам користувач знаходиться на вашому сайті. Як розпорядиться цим багатством - вирішувати тільки вам, залежно від вашої конкретної ситуації. Як правило, буває необхідно або 1) зберегти WMID користувача в базі даних і зробити якусь одноразове дію з користувачем на сайті, або 2) почати для цього відвідувача сесію, прив'язавши до неї WMID, для здійснення подальших дій.

    Повністю код скрипта з нашого прикладу можна скачати звідси . Як все це працює на практиці, можна перевірити тут .

    Що ще потрібно знати

    • Поговоримо трохи про час життя тікета. Якщо ви пам'ятаєте, ми встановлювали цей параметр на самому початку статті. Ми вже говорили про те, що зазвичай потрібно лише одна перевірка тікета. Цього достатньо для того щоб визначити, чи є тікет справжнім, і якщо він таким є - почати виконувати будь-які дії з користувачем вже на своєму сайті (наприклад, стартувати для нього сесію). Постійно перевіряти один і той же тікет необхідності немає. Виходячи з цих міркувань рекомендуємо встановити в настройках час життя тікетів мінімальним, наприклад, 1 або 2 хвилини.
    • Якщо тікет прострочений, то Login.WebMoney поверне retval = 3. В цьому випадку необхідно вважати тікет недостовірним і відправити користувача на повторну авторизацію.
    • Кожна перевірка тікета (XML- або SOAP-інтерфейсом) подовжує термін життя тікета. Наприклад, якщо тікет створений о 20:03 і час його життя встановлено (в настройках) в 20 хвилин, то тікет повинен "померти" о 20:23. Якщо ж ви зробили його перевірку протягом цього періоду, наприклад, о 20:15, то час життя автоматично продовжується ще на 20 хвилин, тобто до 20:35.
    • Історію тікетів, виписаних системою для ваших URL, можна подивитися на сторінці Історія тікетів. Деякі тікети можуть мати час життя менше встановленого в налаштуваннях. Це означає, що користувач авторизувався повторно, і старий тікет, виписаний для нього раніше, був примусово "убитий" системою раніше терміну. Тобто не може одночасно існувати більш одного актуального тікета, виписаного для одного і того ж WMID, який є найважливішим на одному і тому ж URL.
    • Сервіс підтримує також відносини довіри між сайтами. Вони детально описані тут . Коротко це можна описати так. Вася може довірити тікети своїх користувачів Петі, тоді Петя зможе запитувати статус Васін тікетів як своїх власних. Це дозволяє організувати безболісний перехід користувачів з сайту Васі на сайт Петі без повторних авторизаций. Але це вже вищий пілотаж, в класичних ситуаціях ця функція не стане в нагоді. Встановити довіру іншому сайту можна на сторінці Довірені сайти. Введіть в поле Фільтр адресу (можна навіть частина адреси) сайту, якому хочете довірити свої тікети. Даний сайт повинен бути на той час уже зареєстрований в сервісі Login.WebMoney.
    Обговорити цей матеріал

    23.01.2008

    Увага! Всі права на даний матеріал належать сайту owebmoney.ru. Копіювання матеріалу дозволено з обов'язковим зазначенням гіперпосилання на http://owebmoney.ru .

12.04.18
Для учасників системи WebMoney з 26 березня 2018 року доступний висновок за розкладом для WMX, WMH, WML зі зниженою комісією. 12 29.03.18
Багато хто стикався з проблемою, коли хочуть вивести з системи WebMoney, де краще, швидше і безпечно. 16.03.18
Як поповнити гаманець WebMoney через термінал ПриватБанку (Україна). Актуально для жителів України. 13.03.18
Гаманець Bitcoin Cash WMH в системі WebMoney (Вебмані). Як створити, поповнити і вивести Гаманець Bitcoin Cash (WMH) в системі WebMoney (Вебмані). 06.03.18
Після виходу ролика про створення ролика лайткоін (litecoin) багато хто питає про гаманець біткоіни в системі Webmoney.Об цьому наш новий ролик. 03.03.18
Останнім часом надзвичайно популярні онлайн-трансляції, вони отримали назву стрім, а люди, які їх ведуть - стримери. WebMoney надає ун 27.02.18
Гуляючи недавно по Києву, треба було поповнити гаманець WMU, для оплати стільникового, і якщо у вас немає в друзях обмінний пункт =), вам цей ролик допоможе. 25.02.18
У WebMoney з'явився гаманець Litecoin.Кріпто-бум, ... який останнім часом приголомшує електронну комерцію, досяг і WebMoney. Не так давно WebMoney п




Aspx?
Aspx?
Aspx?

Новости

Banwar.org
Наша совместная команда Banwar.org. Сайт казино "Пари Матч" теперь доступен для всех желающих, жаждущих волнения и азартных приключений.