ניתוב פרוקסי ב-gspread 6 לקריאות API ולרענון טוקנים

הגדירו גם את סשן ה-API המורשה של gspread וגם את תעבורת בקשת רענון פרטי הכניסה כשאחד מהם זקוק לפרוקסי:

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)

הקוד משתמש בממשק ה-Client של gspread 6 עם סשן שסופק ועם פרטי הכניסה הקיימים של היישום. הוא מגדיר תעבורה, לא הרשאות גיליון אלקטרוני ולא היקפי OAuth. עבור נקודות קצה ציבוריות של API ושל טוקנים בנתיב ציבורי מורשה, בחרו מועמד HTTP לא מאומת מתוך רשימת פרוקסי HTTP עבור מפת הנתיבים. שמרו על שני הסשנים נקיים מכל חשבון פרוקסי שמור כשמחליפים את המתווך.

AuthorizedSession מוסיף פרטי כניסה לבקשות API ויכול לרענן אותם. בלי auth_request, google-auth יכול ליצור סשן Requests נוסף לתעבורה הזו. ברירות המחדל של פרוקסי בסשן המורשה אינן מגדירות את זה שנוצר באופן עצמאי.

מתאם ה-Request שלמעלה מספק את הנתיב השני הזה במכוון. החזיקו את שני הסשנים כל עוד הם בשימוש, ואז סגרו סשנים בבעלות חיצונית בסוף תחום היישום שלהם.

אלה ברירות מחדל של Session, ולכן מיזוג הסביבה של Requests עדיין יכול להשפיע עליהן. התחשבו בקלטי פרוקסי שעברו בירושה כשנדרש נתיב קבוע.

השתמשו בכתובת שנכשלה כדי להבחין בין סירוב של הגיליון, אתגר פרוקסי וכשל בנקודת הקצה של פרטי הכניסה. טוקן גישה שמור במטמון יכול לגרום לקריאות API להצליח בלי לבצע רענון כלל.