API कॉल्स आणि टोकन रिफ्रेशसाठी gspread 6 प्रॉक्सी राउटिंग
gspread ला प्रॉक्सी-जाणकार अधिकृत सत्र द्या आणि Google क्रेडेन्शियल्स रिफ्रेश करण्यासाठी वापरला जाणारा वेगळा ट्रान्सपोर्ट कॉन्फिगर करा.
यापैकी कोणालाही प्रॉक्सी लागल्यास gspread चे अधिकृत API सत्र आणि क्रेडेन्शियल रिफ्रेश विनंतीचा ट्रान्सपोर्ट दोन्ही कॉन्फिगर करा:
import requests
import gspread
from google.auth.transport.requests import AuthorizedSession, Request
routes = {
'http': 'http://proxy.example:8080',
'https': 'http://proxy.example:8080',
}
token_session = requests.Session()
token_session.proxies.update(routes)
session = AuthorizedSession(
credentials,
auth_request=Request(session=token_session),
)
session.proxies.update(routes)
client = gspread.Client(auth=credentials, session=session)हे gspread 6 चे Client इंटरफेस दिलेले सत्र आणि अॅपच्या विद्यमान क्रेडेन्शियल्ससह वापरते. ते ट्रान्सपोर्ट कॉन्फिगर करते, स्प्रेडशीट परवानग्या किंवा OAuth स्कोप नाही. अनुमत सार्वजनिक मार्गावरील सार्वजनिक API आणि टोकन एंडपॉइंट्ससाठी रूट नकाशासाठी HTTP प्रॉक्सी सूची मधून प्रमाणीकरण न केलेला HTTP उमेदवार निवडा. मध्यस्थ बदलताना दोन्ही सत्रे कोणत्याही साठवलेल्या प्रॉक्सी खात्यापासून मुक्त ठेवा.
AuthorizedSession API विनंत्यांना क्रेडेन्शियल्स जोडते आणि ती रिफ्रेश करू शकते. auth_request शिवाय google-auth त्या रहदारीसाठी अजून एक Requests सत्र तयार करू शकते. अधिकृत सत्रावरील प्रॉक्सी डीफॉल्ट स्वतंत्रपणे तयार केलेले सत्र कॉन्फिगर करत नाहीत.
वरील Request अॅडॉप्टर तो दुसरा मार्ग जाणूनबुजून पुरवतो. वापरादरम्यान दोन्ही सत्रे ठेवा, नंतर त्यांच्या अॅप्लिकेशन व्याप्तीच्या शेवटी बाहेरील मालकीची सत्रे बंद करा.
ही Session डीफॉल्ट आहेत, म्हणून Requests पर्यावरणाचे विलीनीकरण अजूनही त्यांना प्रभावित करू शकते. निश्चित मार्ग आवश्यक असताना वारशाने मिळालेल्या प्रॉक्सी इनपुटचा विचार करा.
अयशस्वी URL वापरून स्प्रेडशीटचा नकार, प्रॉक्सी आव्हान आणि क्रेडेन्शियल एंडपॉइंटचा बिघाड वेगळे करा. कॅश केलेले प्रवेश टोकन API कॉल्स कोणतेही रिफ्रेश न करता यशस्वी करू शकते.