Ccxt: كيفية تعطيل التحقق من شهادة SSL في Python؟

@ مزامنة

1. ما هو نسختك من بايثون؟
2. هل تستخدم إصدار المزامنة أو غير المتزامن من lib؟

@ مزامنة ↓ هل هذا يساعد؟

session = cfscrape.create_scraper()
session.verify = False
ex = getattr(ccxt, exchange)(
    {
        "session": session,
        "enableRateLimit": False,
    }
)

@ مزامنة

1. ما هو نسختك من بايثون؟
2. هل تستخدم إصدار المزامنة أو غير المتزامن من lib؟

Python 3.7.2 واستخدام المزامنة (تم اختباره باستخدام cfscrape وبدونه). سأجربها أيضًا غير متزامن ، فقط للتأكد ، لأنني أعرف أن aiohttp لديه عدد أقل من عمليات التحقق من SSL.

synchronizing أخبرنا إذا كان التعليق أعلاه لا يحل المشكلة لك: https://github.com/ccxt/ccxt/issues/5394#issuecomment -506918563

@ مزامنة ↓ هل هذا يساعد؟

session = cfscrape.create_scraper()
session.verify = False
ex = getattr(ccxt, exchange)(
    {
        "session": session,
        "enableRateLimit": False,
    }
)

تم اختباره مع ما سبق بنفس خطأ التحقق من SSL ، للأسف.

تم الاختبار باستخدام ccxt_async ، ويبدو أنه يعمل بشكل جيد - يمر عبر مكتشف الوكيل أيضًا ، دون التراجع عن أي مشكلة. تمت إضافة شهادة SSL في env (لست متأكدا مما إذا كان سيعمل بدون.)

ومع ذلك ، لا يزال مطلوبًا لـ coinbasepro cfscrape .

تقول هذه الصفحة أنه كان يجب أن تعمل مع إصدار المزامنة أيضًا: https://2.python-requests.org/en/master/user/advanced/#ssl -cert-verification

synchronizing هل يمكنك نشر مقتطف قصير كامل من التعليمات البرمجية لإعادة إنتاجه ، على سبيل المثال ، من 10 إلى 20 سطرًا؟ نحتاج إلى التأكد من عدم وجود تداخل آخر ، لذلك نحتاج إلى مقتطف كامل ، بما في ذلك إنشاء مثيل.

من المؤكد أن kroitor - اعتبارًا من الآن يتم تغليف الكود في خادم واجهة برمجة التطبيقات ، لذا أعطني بعضًا لاستخراج الأسطر ذات الصلة إلى ملف نصي منفصل للاختبار السهل من جانبك.

أيضًا: هل session.verify قيمة منطقية أم سلسلة موقع شهادة؟ من الإصدارات السابقة التي رأيتها هنا ، اعتقدت أنها كانت مجرد علم منطقي.

أيضًا: هل جلسة session.verify منطقية أم سلسلة موقع شهادة؟ من الإصدارات السابقة التي رأيتها هنا ، اعتقدت أنها كانت مجرد علم منطقي.

يجب أن يعمل في كلتا الحالتين ، كمنطق منطقي أو مسار سلسلة ، إذا كانت المستندات صحيحة.

أيضًا: هل جلسة session.verify منطقية أم سلسلة موقع شهادة؟ من الإصدارات السابقة التي رأيتها هنا ، اعتقدت أنها كانت مجرد علم منطقي.

يجب أن يعمل في كلتا الحالتين ، كمنطق منطقي أو مسار سلسلة ، إذا كانت المستندات صحيحة.

يبدو جيدا. أعطني القليل لتجميع المشكلة وصولاً إلى بضعة أسطر من التعليمات البرمجية.

باستخدام الكود التالي:

import ccxt

exchange = ccxt.binance()
exchange.session.verify = False # With, or without line.
fetch = exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
print(fetch)

مع التصدير إلى وكيل man-in-the-middle:

export http_proxy=http://127.0.0.1:8888
export https_proxy=http://127.0.0.1:8888

ما زلت أتلقى خطأ في إصدار المزامنة ccxt . إذا كنت ترغب في اختباره باستخدام الرجل في المنتصف ، فيمكنك العثور عليه في الريبو الخاص بي هنا . فقط قم بتشغيل الملف example/example_server.py .

لقد أدركت للتو سبب نجاحه مع aiohttp هو أنه حتى مع إعداد exchange.session.trust_env و exchange.session.trust_env_aiohttp ، لا تحترم أي من العلامتين المجموعة http_proxy و https_proxy متغير env.

التحديث: aiohttp لا يعمل أيضًا.

async def fetch_stuff():
    exchange = ccxt.binance({"aiohttp_proxy": "http://127.0.0.1:8888", "verify": False})
    fetch = await exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
    await exchange.close()
    return fetch


print(asyncio.get_event_loop().run_until_complete(asyncio.gather(fetch_stuff())))

مع تعيين aiohttp_proxy الضمني (نظرًا لعدم احترام http_proxy و https_proxy ) ، لا تزال عمليات التحقق من SSL ترجع الخطأ. أعرف حقيقة أن aiohttp يستخدم العلم ssl (بدلاً من verify ، مثل مكتبة requests ، لتمكين / تعطيل عمليات تدقيق SSL) ولكن أفترض لا يوجد علم موجود لـ ccxt .

async def fetch_stuff():
    exchange = ccxt.binance({"aiohttp_proxy": "http://127.0.0.1:8888", "verify": False})
    fetch = await exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
    await exchange.close()
    return fetch

↑ هذه ليست طريقة صحيحة لتكوينه. يجب عليك إضافة جلسة غير متزامنة وتعيين verify = False عليها ، قبل تمريرها إلى مُنشئ binance. فئة التبادل المشتقة لا تدعم الخيار verify .

المزيد عنها هنا:

• https://github.com/ccxt/ccxt/blob/master/python/ccxt/async_support/base/exchange.py#L75

قد يكون سلوك المزامنة الخاطئ خطأ في وكيل MITM: https://www.google.com/search؟q=python+https+proxy+ssl+verify+requests. يبدو أنك لست الشخص الوحيد الذي يواجه صعوبات عند استخدام التحقق من البروكسيات + SSL.

async def fetch_stuff():
    exchange = ccxt.binance({"aiohttp_proxy": "http://127.0.0.1:8888", "verify": False})
    fetch = await exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
    await exchange.close()
    return fetch

↑ هذه ليست طريقة صحيحة لتكوينه. يجب عليك إضافة جلسة غير متزامنة وتعيين verify = False عليها ، قبل تمريرها إلى مُنشئ binance. فئة التبادل المشتقة لا تدعم الخيار verify .

عندما تقول هذا ، هل ستكون هذه هي الصيغة الصحيحة؟

async def fetch_stuff():
    exchange = ccxt.binance({"aiohttp_proxy": "http://127.0.0.1:8888"})
    exchange.session.verify = False
    fetch = await exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
    await exchange.close()
    return fetch

print(asyncio.get_event_loop().run_until_complete(asyncio.gather(fetch_stuff())))

قد يكون خطأ في وكيل MITM: https://www.google.com/search؟q=python+https+proxy+ssl+verify+requests. يبدو أنك لست الشخص الوحيد الذي يواجه صعوبات عند استخدام التحقق من البروكسيات + SSL.

أخبرني عن ذلك - يعد وكلاء SLL + كابوسًا ، حيث جئت لاكتشاف ذلك 😩. ومع ذلك ، فإن mitm يعمل كخادم الوجهة للعميل ، لذا فهو لا يقوم في الواقع بإرسال الطلب إلى الخادم الوجهة كما يفعل الوكيل العادي. بدلاً من ذلك ، يقوم ببدء عميل تمت مضاهاته يقوم بذلك ، ثم يعيد طلب العميل الذي تمت مضاهاته إلى العميل الفعلي ، ويقرأ الطلب في الوسط. المشكلة هي الاتصال الأولي بين mitm والعميل بـ ccxt ، ويرجع ذلك أساسًا إلى وجود شهادة موقعة ذاتيًا في المنتصف. حتى مع تعيين علامة verify على "خطأ" ، يبدو أن الخطأ مستمر.

هل سيكون هذا هو الشكل الصحيح؟

لا. سيكون هذا هو التنسيق الصحيح:

import aiohttp
import asyncio

event_loop = asyncio.get_event_loop()

async def fetch_stuff():
    connector = aiohttp.TCPConnector(ssl=False, loop=event_loop)
    session = aiohttp.ClientSession(loop=event_loop, connector=connector, trust_env=True)
    exchange = ccxt.binance({"aiohttp_proxy": "http://127.0.0.1:8888", 'session': session})
    fetch = await exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
    await exchange.close()
    return fetch

print(event_loop.run_until_complete(asyncio.gather(fetch_stuff())))

هل هذا يساعد؟

هل سيكون هذا هو الشكل الصحيح؟

لا. سيكون هذا هو التنسيق الصحيح:

import aiohttp
import asyncio

event_loop = asyncio.get_event_loop()

async def fetch_stuff():
    trust_environment_variables = False
    connector = aiohttp.TCPConnector(ssl=False, loop=event_loop)
    session = aiohttp.ClientSession(loop=event_loop, connector=connector, trust_env=trust_environment_variables)
    exchange = ccxt.binance({"aiohttp_proxy": "http://127.0.0.1:8888", 'session': session})
    fetch = await exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
    await exchange.close()
    return fetch

print(event_loop.run_until_complete(asyncio.gather(fetch_stuff())))

هل هذا يساعد؟

نعم ، لقد فعلت! تلقيت طلبًا في mitm تمت معالجته ولكن لم يتم إرجاعه بشكل صحيح (وهو خطأ من mitm ). أقدر الرجل كثيرا! اسمحوا لي أن أجربها مع المزامنة ccxt .

synchronizing شيء مثل ما ورد أعلاه يجب أن يعمل أيضًا مع الإصدار sync . فقط بحاجة إلى حفر الإنترنت بالطريقة الصحيحة لتكوينها. ومع ذلك ، فإن هذا يتجاوز CCXT ، للأسف.

synchronizing شيء مثل ما ورد أعلاه يجب أن يعمل أيضًا مع الإصدار sync . فقط بحاجة إلى حفر الإنترنت بالطريقة الصحيحة لتكوينها. ومع ذلك ، فإن هذا يتجاوز CCXT ، للأسف.

مفهوم تمامًا - كل ما كنت أتمناه هو CONNECT و GET مع mitm ، من هناك علمت أن ccxt قد أكمل خطوات SSL.

synchronizing هل أنت بخير إذا

سامحني على الأسئلة المتكررة: ولكن مع cfscraper ووظيفة المزامنة القياسية ، هل يمكننا تعيين session ؟ بينما كنت على السلك.

إذا كان هذا خارج المشروع بسبب cfscraper ، فلا تقلق. لقد كانت المساعدة المذكورة أعلاه رائعة بالفعل وأنا أقدرها حقًا.

أيضًا ، غير ذي صلة تمامًا: لا تنخفض مقابل AdBlocker Pro - تم شراؤها من قبل بعض الشركات منذ فترة ، ولا تزال تعرض الإعلانات. الحل مفتوح المصدر هو uBlock Origin الذي يبدو أن قلة قليلة من الناس يدركون أنه موجود وهو أيضًا مانع رائع بالمقارنة (بما في ذلك إعلان YouTube ، شكرًا للرب)

سامحني على الأسئلة المتكررة: ولكن مع وظيفة cfscraper والمزامنة القياسية ، هل يمكننا تحديد جلسة؟

نعم ، يجب أن يكون ذلك ممكنًا. ومع ذلك ، قد تكون هناك أخطاء خارج CCXT:

• https://github.com/kennethreitz/requests/issues/3829

وأود أن أضيف إلى exchange.verify الخيار ل sync النسخة قريبا، وسوف تحتاج الى مساعدتكم لاختباره ضد الوكيل.

سامحني على الأسئلة المتكررة: ولكن مع وظيفة cfscraper والمزامنة القياسية ، هل يمكننا تحديد جلسة؟

نعم ، يجب أن يكون ذلك ممكنًا. ومع ذلك ، قد تكون هناك أخطاء خارج CCXT:

• كينيثريتز / طلبات # 3829

وأود أن أضيف إلى exchange.verify الخيار ل sync النسخة قريبا، وسوف تحتاج الى مساعدتكم لاختباره ضد الوكيل.

تبدو كخطة! مرة أخرى ، أنا أقدر المساعدة. لا تتردد في إغلاق هذه المشكلة وإعادة فتحها عند الحاجة لإجراء الاختبار.

يجب ألا تستغرق synchronizing وقتًا طويلاً ،

يجب ألا تستغرق synchronizing وقتًا طويلاً ،

يبدو الأمر جيدًا معي ، سأكون هنا.

حسنًا ، إليك ما يتعين علينا القيام به:

1. انتظر 15 دقيقة حتى يصل الإصدار 1.18.844
2. قم بتحديث إصدار CCXT الخاص بك (تأكد من تحديثه بشكل صحيح)
3. جرب الكود التالي:

# sync 

import ccxt
exchange = ccxt.binance({'verify': False})
fetch = exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
print(fetch)

أو

# async

async def fetch_stuff():
    exchange = ccxt.binance({"aiohttp_proxy": "http://127.0.0.1:8888", "verify": False})
    fetch = await exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
    await exchange.close()
    return fetch

سنكون سعداء إذا أخبرتنا بما إذا كان قد تم حل المشكلة لك أم لا.

سنكون سعداء إذا أخبرتنا بما إذا كان قد تم حل المشكلة لك أم لا.

Ofc ، سيكون سعيدًا للمساعدة. بالنسبة للميزة async ، المقصود بها تعيين verify مباشرةً على مُنشئ binance ؟

بالنسبة للميزة غير المتزامنة ، المقصود بها تعيين التحقق مباشرة على مُنشئ binance؟

نعم ، لقد أضفت خيار المُنشئ verify لكل من الإصدار sync والإصدار async . يمكنك أيضًا تعيينه بعد ذلك بعد إنشاء مثيل التبادل:

exchange = ccxt.binance()
exchange.verify = False

بالنسبة للميزة غير المتزامنة ، المقصود بها تعيين التحقق مباشرة على مُنشئ binance؟

نعم ، لقد أضفت الخيار verify إلى الإصدارين sync و async .

جميلة. سأعطيها فرصة الآن.

عثر synchronizing على

عثر synchronizing على

ما هو الإصدار الذي يجب أن أبحث عنه؟

@ مزامنة 1.18.844 (القادم).

حسنًا ، لقد وصل ، وأتطلع إلى الاستماع منك.

sync يعمل بالشكل المتوقع على 1.18.844 :

import ccxt as ccxt

exchange = ccxt.binance(
    {
        "proxies": {"http": "http://127.0.0.1:8888", "https": "http://127.0.0.1:8888"},
        "verify": False,
    }
)
fetch = exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
print(fetch)

async لا يعمل مع ما يلي:

import ccxt.async_support as ccxt
import asyncio

async def fetch_stuff():
    exchange = ccxt.binance({"aiohttp_proxy": "http://127.0.0.1:8888", "verify": False})
    fetch = await exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
    await exchange.close()
    return fetch

print(asyncio.get_event_loop().run_until_complete(asyncio.gather(fetch_stuff())))

تم طرح خطأ SSL للرمز أعلاه. ومع ذلك، فإنه يعمل عند تحميل session كما هو موضح سابقا هنا . من المفترض أن verify قد لا يقوم بتعيين علامة ssl في TCPConnector إلى False داخليًا داخل ccxt .

على افتراض ، قد لا يكون التحقق من تعيين علامة ssl في TCPConnector إلى False داخليًا داخل ccxt.

حسنًا ، لقد أضفت تعديلًا آخر إليها ، أخبرنا إذا لم يحل 1.18.845 المشكلة على الجانب async . إغلاق هذا الآن. لا تتردد في إعادة فتحه أو طرح المزيد من الأسئلة ، إن وجدت. سنكون سعداء إذا قمت بالإبلاغ على أي حال.

يبدو جيدًا - سأجربه ، شكرًا لك مرة أخرى.

async لا يعمل مع 1.18.845 مع "verify" : False set.

import ccxt.async_support as ccxt
import asyncio

async def fetch_stuff():
    exchange = ccxt.binance({"aiohttp_proxy": "http://127.0.0.1:8888", "verify": False})
    print(exchange.verify)
    fetch = await exchange.fetch_ohlcv("ETH/BTC", "1m", 1514764800000)
    await exchange.close()
    return fetch

print(asyncio.get_event_loop().run_until_complete(asyncio.gather(fetch_stuff())))

synchronizing لا يعمل مع verify: False ، لكنه يعمل مع https://github.com/ccxt/ccxt/issues/5394#issuecomment -506921151؟

لا تعمل synchronizing مع verify: False ، لكنها تعمل مع # 5394 (تعليق) ؟

هذا صحيح للأسف.

synchronizing هل أنت متأكد من ذلك؟ هذا غريب ، لأنهم يجب أن يكونوا متساوين فنياً ...

synchronizing ah ، nvm ، وجدت خطأ آخر هناك في ترتيب المكالمات ، وسوف يصلحها في لحظة.

synchronizing هل أنت متأكد من ذلك؟ هذا غريب ، لأنهم يجب أن يكونوا متساوين فنياً ...

يبدو أنها مختلفة عند إجراء مزيد من الاختبارات:

import ccxt.async_support as ccxt
import asyncio
import aiohttp

async def fetch_stuff():
    connector = aiohttp.TCPConnector(ssl=False, loop=asyncio.get_event_loop())
    exchange = ccxt.binance({"aiohttp_proxy": "http://127.0.0.1:8888", "verify": False})
    print(exchange.session._connector._ssl)
    print(connector._ssl)
    await exchange.close()

asyncio.get_event_loop().run_until_complete(fetch_stuff())

المخرجات:

<ssl.SSLContext object at 0x10f55c480>
False

synchronizing ah ، nvm ، وجدت خطأ آخر هناك في ترتيب المكالمات ، وسوف يصلحها في لحظة.

رائع ، lmk!

@ مزامنة ، حسنًا ، لنحاول مرة أخرى باستخدام 1.18.846. لسوء الحظ ، لا يمكنني حقًا اختباره على جهاز الصراف الآلي الخاص بي ، فإن مساعدتك في تصحيح الأخطاء محل تقدير كبير! يستغرق البناء التلقائي من 10 إلى 15 دقيقة.

@ مزامنة ، حسنًا ، لنحاول مرة أخرى باستخدام 1.18.846. لسوء الحظ ، لا يمكنني حقًا اختباره على جهاز الصراف الآلي الخاص بي ، فإن مساعدتك في تصحيح الأخطاء محل تقدير كبير! يستغرق البناء التلقائي من 10 إلى 15 دقيقة.

من دواعي سروري يا رجل - أقدر كل العمل الذي تقوم به في نهايتك. سأكون على اطلاع على الإصدار الجديد لتجربته.

https://travis-ci.org/ccxt/ccxt/builds

https://travis-ci.org/ccxt/ccxt/builds

يعمل كما هو متوقع! شكرا لك مرة أخرى ، تحياتي.

تضمين التغريدة
هل يجب علينا تسجيل تحذير إذا تم تعطيل شهادات SSL أو الكتابة فوقها ، حيث قد يؤدي ذلك إلى سرقة المفاتيح؟ هجوم MITM وهناك بعض التبادلات باستخدام بيانات تسجيل الدخول مثل المفاتيح (على سبيل المثال dx.exchange).

تضمين التغريدة
هل يجب علينا تسجيل تحذير إذا تم تعطيل شهادات SSL أو الكتابة فوقها ، حيث قد يؤدي ذلك إلى سرقة المفاتيح؟ هجوم MITM وهناك بعض التبادلات باستخدام بيانات تسجيل الدخول مثل المفاتيح (على سبيل المثال dx.exchange).

دعني أضيف فقط:

• لا يلغي aiohttp ( ccxt.async_support ) تحذير شهادة SSL.
• requests ( ccxt ) لا تحذير شهادة SSL رمي من خلال urllib3 .

brandsimon في هذه الحالة بالذات ، يتم تنفيذ هجوم MITM عمداً من قبل المالك. ولكن بشكل عام ، نعم ، أعتقد أنه سيكون من الرائع تلقي تحذير حتى نبقي الناس على دراية! )

@ مزامنة thx للتلميحات!