Repository navigation
v0.4.0
Breaking changes
Sessionis nowSession(school, cookies)and holds aCookieStore(session.cookies) instead of theedookit_cookies,plus4u_cookiesandcsrf_tokenfields. Build one withSession.from_cookies(school, edookit=…, plus4u=…).edookit_expires_atandis_edookit_expiredare gone;csrf_tokenis now a read-only property taken from theuu.app.csrfcookie.EdookitClientrenews an expired session by itself and retries once. Passon_session_updateto persist each renewed session.SessionExpirednow only surfaces when the session is still expired right after a renewal;AuthErrormeans the Plus4U sign-in expired andlogin()is needed.EdookitClient.sessionreturns a newSessionobject after each renewal, so don't hold on to it.- Any redirect from the portal on a page request (HTTP or the portal's JSON redirect, including the
/oidc/logoutone) now counts as an expired session. - Removed from
pyedookit.auth:build_headers,http_session,REQUEST_TIMEOUT,REDIRECT_STATUSESandCookiesByHost. HTTP now lives inpyedookit.transport.
Sessions stored by 0.3.x still load with Session.from_json(). Sessions written by 0.4.0 use a new JSON format that 0.3.x can't read, so downgrading after a renewal means signing in again.
Improvements
- One transport for every request: cookies rotated by the portal are kept, and cookies the server deletes (
Max-Age=0or a pastExpires) stop being sent. session.plus4u_expires_atshows when the Plus4U sign-in runs out, orNonewhen that's unknown. Plus4U doesn't send an expiry on a silent refresh, so it staysNonefor sessions carried over from 0.3.x until the nextlogin().- Sessions are renewed when the portal reports them expired, instead of on a fixed 30-minute timer. Against a real portal, an idle Edookit session lasted under 30 minutes: polling every 30 minutes gave 4 renewals in 2 hours, all successful.