Skip to content

v0.4.0

Choose a tag to compare

@TFoxik TFoxik released this 10 Oct 18:39
· 16 commits to main since this release
v0.4.0
289e3fe

Breaking changes

  • Session is now Session(school, cookies) and holds a CookieStore (session.cookies) instead of the edookit_cookies, plus4u_cookies and csrf_token fields. Build one with Session.from_cookies(school, edookit=…, plus4u=…). edookit_expires_at and is_edookit_expired are gone; csrf_token is now a read-only property taken from the uu.app.csrf cookie.
  • EdookitClient renews an expired session by itself and retries once. Pass on_session_update to persist each renewed session. SessionExpired now only surfaces when the session is still expired right after a renewal; AuthError means the Plus4U sign-in expired and login() is needed.
  • EdookitClient.session returns a new Session object 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/logout one) now counts as an expired session.
  • Removed from pyedookit.auth: build_headers, http_session, REQUEST_TIMEOUT, REDIRECT_STATUSES and CookiesByHost. HTTP now lives in pyedookit.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=0 or a past Expires) stop being sent.
  • session.plus4u_expires_at shows when the Plus4U sign-in runs out, or None when that's unknown. Plus4U doesn't send an expiry on a silent refresh, so it stays None for sessions carried over from 0.3.x until the next login().
  • 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.