feat(auth): replace cookie scraping with Auth0 OAuth + DPoP-bound refresh

[sslivins]

Hey! First off, thanks for starting and maintaining this integration.
I've been running it for a while and it's been genuinely useful. Really
appreciate the work you've put in. 🙏

That said, the cookie thing has been a recurring headache. Every few
weeks something on Generac's portal shifts (or the cookie just ages
out) and I'm back in DevTools copying values out of a browser, and I
noticed a lot of the recent issues here are folks hitting the same
wall. So I took a stab at fixing it.

My first attempt was actually a script that drove the web login and
got around the bot challenge in front of it. That worked surprisingly
well, but it was still a manual thing I had to run whenever the cookie
died, which kind of defeated the point. Since I'm reasonably familiar
with OAuth, I figured I'd peek at how the mobile app authenticates and
see if it was simple enough to port over. Turned out to be very doable,
and fortunately once you're past the login the API surface the app
talks to is identical to what this integration already uses. So I
pointed the integration at the same Auth0 Universal Login the app
uses, with the same DPoP-bound refresh token flow. End result: real
OAuth, no cookie extraction, automatic token refresh, and a proper
reauth prompt if a refresh ever fails (e.g. password change) instead
of a silently-broken entry.

One thing worth flagging: the app talks to the v5 API where the
integration was on an older version, so I switched everything over to
v5 while I was in there. Nothing I use seems broken by it, but you'll
probably want to take a closer look since you know the surface better
than I do.

What's in here

• auth.py (new): Auth0 Universal Login + DPoP token client.
• API: Bumped endpoints to v5 to match what the mobile app uses.
• Config flow: Email/password user step + working reauth step
  (in-place, no remove-and-re-add).
• Options flow: Configurable scan_interval (default 900s / 15min,
  matching the previous behavior).
• Coordinator: Passes config_entry to DataUpdateCoordinator
  super, which silences the HA 2025+ deprecation warning.
• Entity: device_state_attributes to extra_state_attributes,
  drop a redundant listener wire-up that CoordinatorEntity already
  handles.
• Sensor: Small _safe_float helper so a malformed numeric prop
  reports unknown instead of throwing in native_value.
• Image: Guard against a missing content-type header.
• Tests: Updated end-to-end for the new auth + api surfaces,
  including Auth0 error parsing.
• Translations: New strings for email/password, reauth, and the
  scan interval option.

Migration

No silent fallback. After upgrading, existing entries land in reauth
on the next poll and prompt for MyGenerac email + password once. From
then on tokens are persisted in the config entry and refreshed
automatically.

Testing

• pytest -p no:timeout: full suite green locally (Windows).
• Manual: fresh install, reauth flow, 24h soak with default 15-min
  polls; saw the token refresh at the expected expires_in boundary;
  sensors update normally; reauth re-authenticates without losing the
  entry.

Follow-ups

I've got a few other small PRs coming to clean up some nits I noticed
along the way. Feel free to take or leave whatever you don't want.

Thanks again for the project, and no rush on review. Happy to iterate
on whatever you want changed.

[sslivins]

Quick follow-up - pushed two more commits adding test coverage for the auth changes (refresh-token flow, hidden-input form parser, error paths) plus some defensive bits in the coordinator and sensor code (_safe_float helper, _EMPTY_ITEM sentinel for missing devices). Figured better to have it in one PR than two, but happy to split it back out if you'd rather review separately.

[pjordanandrsn]

Hit a snag using this PR with my MyGenerac account: after password redirected to /authorize/resume, the resume step further redirected to /u/custom-prompt/<id>?state=… (Auth0 Forms — the post-2024 form-builder feature, not the legacy custom prompt). The current _resume_to_code raises on the unexpected scheme.

Account had a one-time consent form pending after the Generac→Auth0 migration. Cleared it interactively in the MobileLink mobile app first (form completion is account-bound; once done, Auth0 skips the prompt for subsequent OAuth flows from any client). Then patched _resume_to_code to handle the case programmatically so future Auth0-Forms triggers don't break setup.

The custom-prompt page is React-rendered (no static <form> to scrape), but the POST endpoint is the same /u/custom-prompt/<id> URL and the body is state=<state>&action=default — Auth0's universal "primary button" convention. Verified live: this clears single-button consent prompts (T&C accept, privacy update, etc.). Loops up to 3 chained prompts before giving up so a chain like consent → privacy → marketing-opt-in works.

If the prompt requires actual interactive action (file upload, MFA setup, profile completion), POST returns 200 with the page again — the handler raises a clear error pointing the user to the MobileLink app.

Patch (against 8c550ca):

auth.py diff (272 lines, mostly the new _handle_custom_prompt + a few extra step= log lines for diagnostics)

$(cat /tmp/generac-prompt-patch.diff)

64/64 tests still pass. Happy to open this as a PR against your pr3-email-password-auth branch if you'd prefer — just figured a comment with the diff was lower-friction since the parent PR is already waiting on review.