Stopped working about checkreceiptsdk HOT 61 CLOSED

Многие хедеры не обязательные.
Например, от id устройства ничего не зависит при получении чека, возможно зависит сама сессия, но это не точно.
Сколько живет сессия - хз.
Используйте следующую информацию на свой страх и риск.
Секрет приложения видимо уникальный для каждого экземпляра.
Перед верификацией есть еще запрос с капчей.

VERIFY POST
curl -H 'Host: irkkt-mobile.nalog.ru:8888' -H 'Accept: /' -H 'Device-OS: iOS' -H 'Device-Id: XXXXXXXXXXXXXXXXXXXXXXXXXX' -H 'If-None-Match: W/"d9-e3/qq888888QYYu0us9DluUwsjCvs"' -H 'clientVersion: 2.8.2' -H 'Accept-Language: ru-RU;q=1, en-US;q=0.9' -H 'User-Agent: billchecker/2.8.2 (iPhone; iOS 13.4; Scale/2.00)' -H 'Content-Type: application/json' --data-binary '{"phone":"+79999999999","client_secret":"YYYYYYYYYYYYYYYYYYYYYYYYYYYY","code":"9999"}' --compressed 'https://irkkt-mobile.nalog.ru:8888/v2/auth/phone/verify'

{"sessionId":"ZZZZZZZZZZZZZZZZZZZZZZZZZZZ:CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC","refresh_token":"HHHHHHHHHHHHHHHHHHHHHHHHHHHHHH","phone":"+79999999999","name":"SomeName","email":"[email protected]"}

TICKET POST
request
curl -H 'Host: irkkt-mobile.nalog.ru:8888' -H 'Accept: /' -H 'Device-OS: iOS' -H 'Device-Id: XXXXXXXXXXXXXXXXXXXXXXXXXX' -H 'If-None-Match: W/"39-F1DNS6f+72gvhYWk2K1kVinBab8"' -H 'clientVersion: 2.8.2' -H 'Accept-Language: ru-RU;q=1, en-US;q=0.9' -H 'sessionId: ZZZZZZZZZZZZZZZZZZZZZZZZZZZ:CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC' -H 'User-Agent: billchecker/2.8.2 (iPad; iOS 13.4; Scale/2.00)' -H 'Content-Type: application/json' --data-binary '{"qr":"t=20200800T1111&s=999.99&fn=111111111&i=22222&fp=3333&n=1"}' --compressed 'https://irkkt-mobile.nalog.ru:8888/v2/ticket'

response {"kind":"kkt","id":"UUUUUUUUUUUUUUUUUUUUUUUU","status":0}

TICKET GET
request
curl -H 'Host: irkkt-mobile.nalog.ru:8888' -H 'sessionId: ZZZZZZZZZZZZZZZZZZZZZZZZZZZ:CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC' -H 'Device-OS: iOS' -H 'clientVersion: 2.8.2' -H 'Device-Id: XXXXXXXXXXXXXXXXXXXXXXXXXX' -H 'Accept: /' -H 'User-Agent: billchecker/2.8.2 (iPad; iOS 13.4; Scale/2.00)' -H 'Accept-Language: ru-RU;q=1, en-US;q=0.9' --compressed 'https://irkkt-mobile.nalog.ru:8888/v2/tickets/UUUUUUUUUUUUUUUUUUUUUUUU'

response
{"id":"UUUUUUUUUUUUUUUUUUUUUUUU","status":1,"kind":"kkt","createdAt":"2020-08-01T99:99:11+02:00","statusDescription":{},"qr":"t=20200800T1111&s=999.99&fn=111111111&i=22222&fp=3333&n=1","operation":{"date":"2020-08-00T11:11:00+09:00","type":1,"sum":99999},"process":[],"query":{"operationType":1,"sum":99999,"documentId":22222,"fsId":"111111111","fiscalSign":"3333","date":"2020-08-00T11:11"}}

from checkreceiptsdk.

А какой запрос будет для проверки чека на корректность без авторизации?

В официальном приложении можно проверять чеки на корректность, авторизация не нужна.

Запрос такой:

GET https://irkkt-mobile.nalog.ru:8888/v2/check/ticket?fsId=XXX&operationType=1&documentId=XXX&fiscalSign=XXX&date=2020-09-14T12:00:00&sum=XXX

fsId — ФН
operationType — тип операции (1 – приход, 2 – возврат прихода, 3 – расход, 4 – возврат расхода)
documentId — ФД
fiscalSign — ФП
date — дата покупки
sum — сумма чека (без разделителей)

При корректном чеке статус ответа будет 204 (пустая страница), при некорректном покажет ошибку

from checkreceiptsdk.

@3bl3gamer благодарю за такой подробный ответ! Дальнейшие поиски по приведённым вами кускам кода подтвердили предположение о получении client_secret из хэша подписи приложения. Получить исходное значение client_secret у меня получилось следующим образом:

1. извлекаем из .apk приложения файл подписи в формате PKCS#7 BNDLTOOL.RSA
2. с помощью openssl извлекаем из него сертификат openssl pkcs7 -in BNDLTOOL.RSA -inform DER -print_certs получаем на выходе:

subject=/C=Russia/ST=Nizhegorodskaya oblast/L=N.Novgorod/O=Studio_TG/OU=RPO/CN=Sachkov Dmitry
issuer=/C=Russia/ST=Nizhegorodskaya oblast/L=N.Novgorod/O=Studio_TG/OU=RPO/CN=Sachkov Dmitry
-----BEGIN CERTIFICATE-----
MIIDpTCCAo2gAwIBAgIED1QoaDANBgkqhkiG9w0BAQsFADCBgjEPMA0GA1UEBhMG
UnVzc2lhMR8wHQYDVQQIExZOaXpoZWdvcm9kc2theWEgb2JsYXN0MRMwEQYDVQQH
EwpOLk5vdmdvcm9kMRIwEAYDVQQKDAlTdHVkaW9fVEcxDDAKBgNVBAsTA1JQTzEX
MBUGA1UEAxMOU2FjaGtvdiBEbWl0cnkwHhcNMTYxMDEzMTM1MzI3WhcNNDExMDA3
MTM1MzI3WjCBgjEPMA0GA1UEBhMGUnVzc2lhMR8wHQYDVQQIExZOaXpoZWdvcm9k
c2theWEgb2JsYXN0MRMwEQYDVQQHEwpOLk5vdmdvcm9kMRIwEAYDVQQKDAlTdHVk
aW9fVEcxDDAKBgNVBAsTA1JQTzEXMBUGA1UEAxMOU2FjaGtvdiBEbWl0cnkwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+7/Mgd9ucvuNZhUWpxfkYZ+Z
+YhlFB7ITcQsyF8CN1iFmrvnNCkl6Oz1FgkbsjTtR+r7NG0gc4aqyqftYO6aBhNX
JUWU6jQZMhGgWtQbMqjXKUchsq7y5D4n2MUWC2UFrVcK5Ao56N2rijacUMsLLkkv
STwPWEwjBXdU5IcbhFXOuk0k/hn+G3e8ZT+PUZ4f4WxWL1HDgn5sE6dzGyyPe77/
2I4OsiGS8/Llsr0B2xS3DEf9STFny9H/1J9MmvIi/vM1VVq+UKEBmpXURuGjQZp3
AXbJk/4EQkirMnVOl7ts/B05/35qt6+NJJp0w31Awr27GPNVzgVNB13crCXHAgMB
AAGjITAfMB0GA1UdDgQWBBQkneiTl7Dz+WlDLc4ylQeDd+VbuzANBgkqhkiG9w0B
AQsFAAOCAQEANs56jQAro5KodzMWEl3j4dYUVN2/PrH4msI8utyTjuR7K6gq6BrV
9BwqseBXxNw6R5Vk/ZidbJSFT9sv5yYUNrs8Ybw/AiABF/M3DRV3wvjAVRhQFLv9
QpRFCpMbzi/TSK3+fWtT33oGV58uRPd6caD9vRwNeNzKHUVIK2R4qGiYkboAfd8i
p6c+cAUFuaCaI+CuGyVx/XfkUkkI1RPpYPi2f90G1ZsEU1ZUya4ljxeFCtkjmHYl
tawfAGZvteZ20GuAw2fu/7ExU0Ei7u1ltNzsF3LbH1a+BDHPI2y1NtXndoh5Uou6
V9b7lMI0ilAKP8XYPuzu7JdIhaeLH9j0DQ==
-----END CERTIFICATE-----

3. то что между BEGIN и END декодируем в байты и вычисляем от этого SHA-1. На Python например вот так:

import base64
import hashlib
cert_bytes = base64.b64decode("MIIDpTCCAo2gAwIBAgIED1QoaDANBgkqhkiG9w0BAQsFADCBgjEPMA0GA1UEBhMGUnVzc2lhMR8wHQYDVQQIExZOaXpoZWdvcm9kc2theWEgb2JsYXN0MRMwEQYDVQQHEwpOLk5vdmdvcm9kMRIwEAYDVQQKDAlTdHVkaW9fVEcxDDAKBgNVBAsTA1JQTzEXMBUGA1UEAxMOU2FjaGtvdiBEbWl0cnkwHhcNMTYxMDEzMTM1MzI3WhcNNDExMDA3MTM1MzI3WjCBgjEPMA0GA1UEBhMGUnVzc2lhMR8wHQYDVQQIExZOaXpoZWdvcm9kc2theWEgb2JsYXN0MRMwEQYDVQQHEwpOLk5vdmdvcm9kMRIwEAYDVQQKDAlTdHVkaW9fVEcxDDAKBgNVBAsTA1JQTzEXMBUGA1UEAxMOU2FjaGtvdiBEbWl0cnkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+7/Mgd9ucvuNZhUWpxfkYZ+Z+YhlFB7ITcQsyF8CN1iFmrvnNCkl6Oz1FgkbsjTtR+r7NG0gc4aqyqftYO6aBhNXJUWU6jQZMhGgWtQbMqjXKUchsq7y5D4n2MUWC2UFrVcK5Ao56N2rijacUMsLLkkvSTwPWEwjBXdU5IcbhFXOuk0k/hn+G3e8ZT+PUZ4f4WxWL1HDgn5sE6dzGyyPe77/2I4OsiGS8/Llsr0B2xS3DEf9STFny9H/1J9MmvIi/vM1VVq+UKEBmpXURuGjQZp3AXbJk/4EQkirMnVOl7ts/B05/35qt6+NJJp0w31Awr27GPNVzgVNB13crCXHAgMBAAGjITAfMB0GA1UdDgQWBBQkneiTl7Dz+WlDLc4ylQeDd+VbuzANBgkqhkiG9w0BAQsFAAOCAQEANs56jQAro5KodzMWEl3j4dYUVN2/PrH4msI8utyTjuR7K6gq6BrV9BwqseBXxNw6R5Vk/ZidbJSFT9sv5yYUNrs8Ybw/AiABF/M3DRV3wvjAVRhQFLv9QpRFCpMbzi/TSK3+fWtT33oGV58uRPd6caD9vRwNeNzKHUVIK2R4qGiYkboAfd8ip6c+cAUFuaCaI+CuGyVx/XfkUkkI1RPpYPi2f90G1ZsEU1ZUya4ljxeFCtkjmHYltawfAGZvteZ20GuAw2fu/7ExU0Ei7u1ltNzsF3LbH1a+BDHPI2y1NtXndoh5Uou6V9b7lMI0ilAKP8XYPuzu7JdIhaeLH9j0DQ==")
hash = hashlib.sha1()
hash.update(cert_bytes)
hash.hexdigest()

4. На выходе получаем:
   '9a700b8caa1baea4ffb02f6e9b8c1795a9979cea'
   Уже сейчас можно сравнить это с выводом openssl pkcs7 -in BNDLTOOL.RSA -inform DER -print_certs | openssl x509 -fingerprint -noout:
   SHA1 Fingerprint=9A:70:0B:8C:AA:1B:AE:A4:FF:B0:2F:6E:9B:8C:17:95:A9:97:9C:EA
   Как можно убедиться - результат идентичен.
5. Ну и в конце получим результат хэширования закодированный в Base64 base64.b64encode(hash.digest()).decode("utf-8"):
   'mnALjKobrqT/sC9um4wXlamXnOo='

from checkreceiptsdk.

@titov-vv учитывая предоставленную вами информацию, у меня тоже напрашивается вывод, что так оно и есть. Вот тут, теперь уже видимо ошибочно, вы когда-то писали иное:

3. client_secret разных для разных установок приложения...

Но это, как я понимаю, из-за недостатка информации о работе приложения на тот момент.

Ещё хочу заметить, что в последней версии приложения выпилили капчу! Теперь для получения SMS в запросе нужны только параметры "phone" и "client_secret".

from checkreceiptsdk.

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

Сам процесс теперь выглядит следующим образом:

1. Послал POST запрос на аутентификацию (телефон и капча в параметрах)
2. Послал POST с верификацией (телефон, капча, секрет приложения, код из смс), при успехе возвращает сессию
3. Запрос чека (все делается под полученной ранее сессией с device_id):
   3.1 POST с qr строкой, получаешь ticketID
   3.2 GET на адрес с ticketID

from checkreceiptsdk.

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

Сам процесс теперь выглядит следующим образом:

1. Послал POST запрос на аутентификацию (телефон и капча в параметрах)
2. Послал POST с верификацией (телефон, капча, секрет приложения, код из смс), при успехе возвращает сессию
3. Запрос чека (все делается под полученной ранее сессией с device_id):
   3.1 POST с qr строкой, получаешь ticketID
   3.2 GET на адрес с ticketID

А можно по-подробней, какие запросы и на какие адреса теперь нужно отправлять?

from checkreceiptsdk.

И откуда брать капчу.

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

from checkreceiptsdk.

В общем целом затык только в сессии, сами запросы тривиальные. Кто найдет способ без гемора ее получать - тот молодец)

from checkreceiptsdk.

В общем целом затык только в сессии, сами запросы тривиальные. Кто найдет способ без гемора ее получать - тот молодец)

Здравствуйте. А вы не могли бы показать запрос аутентификации, который идет перед верификацией ? и если возможно запрос, который получает картинку капчи. Спасибо!

from checkreceiptsdk.

Насколько я понял, сессия на 24 часа. Затем нужно слать POST на https://irkkt-mobile.nalog.ru:8888/v2/mobile/users/refresh указав client_secret и refresh_token. В ответ получаешь новый sessionId и refresh_token.

from checkreceiptsdk.

Здравствуйте. А вы не могли бы показать запрос аутентификации, который идет перед верификацией ? и если возможно запрос, который получает картинку капчи. Спасибо!

REQUEST

POST
-H 'Host: irkkt-mobile.nalog.ru:8888'
-H 'Content-Type: application/json'
-H 'Device-OS: iOS'
-H 'clientVersion: 2.8.2'
-H 'Device-Id: ........'
-H 'Accept: /'
-H 'User-Agent: billchecker/2.8.2 (iPhone; iOS 13.4; Scale/2.00)'
-H 'Accept-Language: ru-RU;q=1, en-US;q=0.9'

data '{"phone":"+79999999999","os":"iOS","captcha":"YYYYYYYYYYYYYYY","client_secret":"11111111111111111111"}'
URL 'https://irkkt-mobile.nalog.ru:8888/v2/auth/phone/request'

RESP headers 0 bytes body 0 bytes

from checkreceiptsdk.

Насколько я понял, сессия на 24 часа. Затем нужно слать POST на https://irkkt-mobile.nalog.ru:8888/v2/mobile/users/refresh указав client_secret и refresh_token. В ответ получаешь новый sessionId и refresh_token.

огонь) тоже заметил что сессия протухает через день
скиньте пожалуйста хедеры и формат данных для запроса на рефреш

from checkreceiptsdk.

Насколько я понял, сессия на 24 часа. Затем нужно слать POST на https://irkkt-mobile.nalog.ru:8888/v2/mobile/users/refresh указав client_secret и refresh_token. В ответ получаешь новый sessionId и refresh_token.

огонь) тоже заметил что сессия протухает через день
скиньте пожалуйста хедеры и формат данных для запроса на рефреш

POST /v2/mobile/users/refresh HTTP/1.1
Host: irkkt-mobile.nalog.ru:8888
Device-OS: Android
Device-ID: 1234
Content-Type: application/json

{
"client_secret": "",
"refresh_token": ""
}

Response:
{
"sessionId": "",
"refresh_token": ""
}

Также после рефреша старые сессии продолжают работать.

from checkreceiptsdk.

А можно делать запрос пока старая сессия еще активна?

from checkreceiptsdk.

Да

from checkreceiptsdk.

а если сессия протухла - рефреш поможет?

from checkreceiptsdk.

Должно. Само приложение шлет рефреш только если получит 401 от первого запроса.

from checkreceiptsdk.

Почему-то 400 вернул. Это точно все нужные хедеры?

from checkreceiptsdk.

Вроде да, покажите ваш запрос

from checkreceiptsdk.

Вроде да, покажите ваш запрос

сегодня все отработало, хз в чем проблема была вчера
POST
curl -H 'Host: irkkt-mobile.nalog.ru:8888' -H 'Device-OS: iOS' -H 'Device-Id: 999999999999999999999999' -H 'Content-Type: application/json' --data-binary '{"client_secret":"11111111111111111111", "refresh_token": "222222222222222222"}' --compressed 'https://irkkt-mobile.nalog.ru:8888/v2/mobile/users/refresh'

from checkreceiptsdk.

Device-Id в refresh запросе может быть любым

from checkreceiptsdk.

Откуда в первый раз брать client_secret и refresh_token?

from checkreceiptsdk.

Откуда в первый раз брать client_secret и refresh_token?

Отправить капчу и код из смс

from checkreceiptsdk.

Вроде да, покажите ваш запрос

У меня появилось подозрение что секрет у приложения один на все клиенты.
У вашего приложения тоже секрет заканчивается на "XYQ4=" и в середине есть "\/"?

from checkreceiptsdk.

Вроде да, покажите ваш запрос

У меня появилось подозрение что секрет у приложения один на все клиенты.
У вашего приложения тоже секрет заканчивается на "XYQ4=" и в середине есть "\/"?

Нет, но на разных эмуляторах у меня секрет одинаковый

from checkreceiptsdk.

Здравствуйте. А вы не могли бы показать запрос аутентификации, который идет перед верификацией ? и если возможно запрос, который получает картинку капчи. Спасибо!

REQUEST

POST
-H 'Host: irkkt-mobile.nalog.ru:8888'
-H 'Content-Type: application/json'
-H 'Device-OS: iOS'
-H 'clientVersion: 2.8.2'
-H 'Device-Id: ........'
-H 'Accept: /'
-H 'User-Agent: billchecker/2.8.2 (iPhone; iOS 13.4; Scale/2.00)'
-H 'Accept-Language: ru-RU;q=1, en-US;q=0.9'

data '{"phone":"+79999999999","os":"iOS","captcha":"YYYYYYYYYYYYYYY","client_secret":"11111111111111111111"}'
URL 'https://irkkt-mobile.nalog.ru:8888/v2/auth/phone/request'

RESP headers 0 bytes body 0 bytes

@TerehinAV, Благодарю. Этот? Если да, тогда откуда брать капчу?
UPD: и код из смс это который при регистрации получали, или какой-то новый?

from checkreceiptsdk.

@TerehinAV, Благодарю. Этот? Если да, тогда откуда брать капчу?
UPD: и код из смс это который при регистрации получали, или какой-то новый?

В этом то и затык. Капча походу гугловая/эпловая. Какой запрос ее отдает - хз. Код из смс.

from checkreceiptsdk.

Приветствую, коллеги. Аналогично столкнулись с изменением api налоговой. Сидели на нем. В поиске альтернативы обнаружили такой сервис: проверка чека http://proverkacheka.com/ Есть свое api (предоставляют по обращению), распознает QR-коды. На ура распознали и вернули все запрашиваемые чеки. Как вариант - рекомендую.

from checkreceiptsdk.

Приветствую, коллеги. Аналогично столкнулись с изменением api налоговой. Сидели на нем. В поиске альтернативы обнаружили такой сервис: проверка чека http://proverkacheka.com/ Есть свое api (предоставляют по обращению), распознает QR-коды. На ура распознали и вернули все запрашиваемые чеки. Как вариант - рекомендую.

Подозреваю что под капотом у них та же кухня) Открытое API под такие цели не дают.

from checkreceiptsdk.

Приветствую, коллеги. Аналогично столкнулись с изменением api налоговой. Сидели на нем. В поиске альтернативы обнаружили такой сервис: проверка чека http://proverkacheka.com/ Есть свое api (предоставляют по обращению), распознает QR-коды. На ура распознали и вернули все запрашиваемые чеки. Как вариант - рекомендую.

Подозреваю что под капотом у них та же кухня) Открытое API под такие цели не дают.

Сервис использует разные варианты в том числе и Открытое API. Для мобильных приложений открытое API не вариант (идет привязка к IP адресу)

from checkreceiptsdk.

Сервис использует разные варианты в том числе и Открытое API. Для мобильных приложений открытое API не вариант (идет привязка к IP адресу)

а ребята молодцы) без особого напряга и клиента собирают кучу инфы по потребительской корзине :)

from checkreceiptsdk.

Прошлый способ перестал работать, описали клиента в свежем материале блога LEFTJOIN.

Код доступен в публичном репо гитхаба: https://github.com/valiotti/get-receipts

from checkreceiptsdk.

Делаю запрос:
POST /v2/ticket HTTP/1.1
Host: irkkt-mobile.nalog.ru:8888
sessionid: 5f3f3be4947576140669ed46:1e7c0c96-51d2-4e44-9d46-b0b8dab0f72b
Content-Type: application/json

{"qr":"t=20200800T1111&s=999.99&fn=111111111&i=22222&fp=3333&n=1"}

И в ответ: код ответа=400 fiscalData parameter is required
Что не так?

Вы указали fn - фискальный номер, fp - фискальный признак, но не указали fiscalData. Следуя логике вы должны добавить в запрос ещё fd=<ФД из чека>. То есть запрос будет
{"qr":"t=20200800T1111&s=999.99&fn=111111111&i=22222&fp=3333&fd=44444&n=1"}

from checkreceiptsdk.

Не надо ничего лишнего туда запихивать. Только то что было в QR, если не ошибаюсь, у сервера есть валидатор в том числе на лишние параметры.
Если формируете qr_data вручную - посмотрите любой чек и сопоставьте параметры реального чека, и того, для которого вы хотите вручную заполнить. Как только все правильно заполните - сервер вам вернет детализацию.

from checkreceiptsdk.

Проблема решилась после передачи заголовка content-length

from checkreceiptsdk.

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

from checkreceiptsdk.

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

from checkreceiptsdk.

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

from checkreceiptsdk.

А какой запрос будет для проверки чека на корректность без авторизации?

В официальном приложении можно проверять чеки на корректность, авторизация не нужна.

from checkreceiptsdk.

Мне не корректность надо, мне надо содержимое чека, для внутренней аналитики

from checkreceiptsdk.

и я хочу просто авторизоваться сам и взять сессию и использовать для api

from checkreceiptsdk.

@lelik
А какой запрос будет для проверки чека на корректность без авторизации?

В официальном приложении можно проверять чеки на корректность, авторизация не нужна.

поддерживаю вопрос

from checkreceiptsdk.

Откуда в первый раз брать client_secret и refresh_token?

Отправить капчу и код из смс

А как получить капчу и код из смс?

from checkreceiptsdk.

@strangerxx

как получить сессию, чтобы потом её использовать?

Андроид? Если телефон рутован (или есть другая возможность заглянуть в файлы приложения, например через бекапы / с эмулятора), можно вынуть сессию из /data/data/ru.fns.billchecker/shared_prefs/ru.fns.billchecker_preferences.xml.

Чтоб делать запросы, нужен KEY_ACCESS_TOKEN из этого файла. Он, как выше писали, протухает через день. Так что можно из того же файла вынуть VERSION (это client_secret), KEY_REFRESH_TOKEN и делать при необходимости /v2/mobile/users/refresh.

Подробнее — тут (ну и выше/ниже тоже).

from checkreceiptsdk.

Спасибо большое за ответ, буду пробовать это уже более понятно мне

from checkreceiptsdk.

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

from checkreceiptsdk.

@Ususucsus

У меня появилось подозрение что секрет у приложения один на все клиенты.
У вашего приложения тоже секрет заканчивается на "XYQ4=" и в середине есть "/"?

Нет, но на разных эмуляторах у меня секрет одинаковый

Добрый день. Тогда предположу, что Ваш client_secret заканчивается на "XnOo="?

from checkreceiptsdk.

@sasha127 мой заканчивается на XnOo= и имеет "/" в середине.
'=' в конце как-то намекает что это base64 или что-то подобное... а то, что это записано в поле VERSION и ограниченное количество попадавшихся значений рождает подозрение что это хэш от строки версии программы или чего-то подобного.

from checkreceiptsdk.

@sasha127 мой заканчивается на XnOo= и имеет "/" в середине.
'=' в конце как-то намекает что это base64 или что-то подобное... а то, что это записано в поле VERSION и ограниченное количество попадавшихся значений рождает подозрение что это хэш от строки версии программы или чего-то подобного.

@titov-vv благодарю за ответ! Мой начинается на "mnAL" и тоже есть "/" в середине. Встречались ли Вам иные рабочие значения кроме этого и упомянутого здесь "CLIENT_SECRET=IyvrAbKt9h/8p6a7QPh8gpkXYQ4="?

Да, это действительно закодированное Base64 значение. И судя по длине (20 байт) декодированных данных это SHA-1 от чего-то там. Значение генерируется сразу при первом запуске приложения. У меня значение получалось неизменным независимо от:

1. версии приложения (начиная с 2.8.0 и до последней (проверены многие, но не все)),
2. версии Android (несколько, с 5-й по 9-ю),
3. аккаунта Google (и без аккаунта тоже),
4. устройства (смартфоны, планшет, ПК с Android x86),
5. местоположения (через Fake GPS),
6. наличия и отсутствия соединения с сетью интернет.

from checkreceiptsdk.

@sasha127 я видел 2 значения - Iyvr... и mnAL.... Как видите упомянутый там - для версии приложения 2.9.0 на iOS. Мы с вами очевидно на Android. Из того что вы пишете - похоже эта строка просто показывает платформу на которой работает приложение.

from checkreceiptsdk.

Прошу @Ususucsus и @3bl3gamer прокомментировать вышеизложенное начиная отсюда.

from checkreceiptsdk.

@sasha127 да я глубоко не копал: с автообновлением токена разобрался и успокоился :)

Но раз уж спросили... Да, у меня этот секрет тоже начинается на mnAL, заканчивается на XnOo=. ОС — Андроид.

Если нужны подробности, можно засунуть .apk в какой-нибудь декомиплер (вот браузерный например http://www.javadecompilers.com/apk) и устроить поиск по сорцам.

Сначала — по "VERSION" (под таким именем приложение сохраняет client_secret в ru.fns.billchecker_preferences.xml). Там будет два результата: ...getString("VERSION", "") и

public void mo45888n(String str) {
  C6404l.m17228d(str, "version");
  this.f18024b.edit().putString("VERSION", str).commit();
}

Т.е. пишет его только метод mo45888n. Ищем его вызов, он на все сорцы один:

String a = aVar3.mo44320a(activity);
if (a != null) {
    mo44084z().mo45888n(a);

Значение приходит из mo44320a, ищем его объявление:

public final String mo44320a(Context context) {
    // ...
        Signature[] signatureArr = context.getPackageManager().getPackageInfo(context.getPackageName(), 64).signatures;
        int length = signatureArr.length;
        int i = 0;
        while (i < length) {
            Signature signature = signatureArr[i];
            MessageDigest instance = MessageDigest.getInstance("SHA");
            instance.update(signature.toByteArray());
            String encodeToString = Base64.encodeToString(instance.digest(), 2);
            // ...
            i++;
            str = encodeToString;
    // ...
    return str;
}

Я в андроидных апи особо на разбираюсь, но это похоже на вычисление хеша от подписи приложения (как и предполагал @sasha127).

from checkreceiptsdk.

Вот тут, теперь уже видимо ошибочно, вы когда-то писали иное:

Да, думаю это была ошибка, сделанная впопыхах. Я вчера проверял свои заметки - там в итоге только 2 строки.
Плюс после сообщения @3bl3gamer я вспомнил, что уже тоже ковырял этот андроидный код в прошлом году и пришёл к таким же выводам. Просто ветка заглохла и вероятно поэтому я не отписался, а потом и забыл.

Ещё хочу заметить, что в последней версии приложения выпилили капчу! Теперь для получения SMS в запросе нужны только параметры "phone" и "client_secret".

О, а вот за эту новость большое спасибо. Я в своём клиенте не делал SMS только из-за того, что так и не смог научиться нормально загружать андроидную капчу на ПК. Попробую в ближайшее время прикрутить, т.к. это самый удобный способ авторизоваться.

from checkreceiptsdk.

Добрый день!
Подскажите — работает ли у вас получение session_id через API ФНС ?

Стал получать 500 ошибку сервера. Пользуюсь проектом https://github.com/valiotti/get-receipts. Ошибка при выполнении post-запроса в методе set_session_id()

from checkreceiptsdk.

Подскажите — работает ли у вас получение session_id через API ФНС ?

Вроде не было проблем вчера-позавчера, но понаблюдаю.

from checkreceiptsdk.

Ещё хочу заметить, что в последней версии приложения выпилили капчу! Теперь для получения SMS в запросе нужны только параметры "phone" и "client_secret".

А про какой запрос речь идёт? Попробовал через /v2/auth/phone/request и получил в ответ 400 Client request error

from checkreceiptsdk.

А про какой запрос речь идёт? Попробовал через /v2/auth/phone/request и получил в ответ 400 Client request error

@titov-vv, речь идёт именно об этом запросе. Данные нужно отправлять в формате JSON. 400 Client request error получается если отправлять данные в обычном post формате. При правильном запросе приходит пустой ответ с кодом 204.

from checkreceiptsdk.

@sasha127, вот так и делал.... Делаю POST с такой вот начинкой:
{"client_secret":"mnALjKobrqr/sC7um3wXlamXnOo=", "phone":"+79871234567"}
Я помню что 204 приходило до появления капчи... но у меня старый код не сохранился, сделал вот новый по образу и подобию и что-то не выходит...

from checkreceiptsdk.

@titov-vv, у вас в clien_secret ошибки. Должно быть mnALjKobrq T/sC9 um 4 wXlamXnOo=. С некорректным client_secret тоже возвращает 400 Client request error.

from checkreceiptsdk.

@sasha127 , блин, точно... спасибо за помощь. Хз откуда я его кривой скопипасил. Всё есть и 204, и SMS.

from checkreceiptsdk.

Ребят, я так понимаю этот тикет больше не актуален (поправьте, если ошибаюсь).
Для всех остальных дискуссий прошу переходить сюда.
Если есть какие-то проблемы с библиотекой, то смело открывайте новые тикеты.

from checkreceiptsdk.