n.siegfried/Project-SDE-WP-Suite
3
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

T10.7 - a fake-OIDC-provider test seam, mirroring ldap_fake.py

Browse Source 
Only two calls actually touch the network: Authlib's authorize_redirect and
authorize_access_token. server/okta_fake.py stands in for both, dispatched from
okta_auth._build_oauth() before the real Okta config is even considered, and
production-refusing the same way ldap_fake.is_active() does - a non-SQLite
DATABASE_URL means production, full stop, no matter what WP_OKTA_FAKE_DIRECTORY
says. Everything this app itself decides stays real: the ?next= open-redirect
guard, the disabled-account check, JIT provisioning, and which claim carries
identity all run unmodified in app.py's okta_login()/okta_callback().

The fake needed one thing ldap_fake.py never did: something to actually redirect
the browser to and back, since Okta's real flow leaves the site and LDAP's never
did. Two routes stand in for Okta's own sign-in screen - a plain picker listing
whatever WP_OKTA_FAKE_DIRECTORY defines, and a consent step that hands back an
authorization code (or an error) at okta_callback, exactly the shape a real Okta
redirect would carry. Both are registered in app.py only when the fake is active
at import time, so in production they do not exist at all, not merely refuse a
request - confirmed by starting the app with the env var unset and checking
app.routes directly.

tests/browser_check.py's start_server() takes an optional extra_env now (no
existing caller passes a third positional arg, so none of the ~40 files that
import it needed touching) and sets WP_OKTA_FAKE_DIRECTORY unconditionally,
same reasoning the LDAP predecessor used: almost nothing signs in (seed() mints
tokens directly), but the one check that does should not fail mysteriously.

tests/url_state_check.py scenario 2, SKIPPED since T10.4, is un-skipped and now
drives the real round trip: login.html's own button, the fake picker page, the
fake consent redirect, okta_callback(). Carries forward the LDAP predecessor's
own bug fix too - asserting the app actually LEFT login.html, not just that
wp-creation-index.html appears somewhere in the URL (which the ?next= parameter
alone would satisfy).

tests/okta_auth_check.py is new, mirroring ldap_auth_check.py's two-layer shape:
guards that need no server (the production refusal, single-use/replay on the
authorization code), then a real running app for sign-in itself - an existing
admin surviving unchanged, JIT provisioning at the lowest role, a disabled
account refused despite Okta approving it, an unsolicited callback hit refused
without a 500, a tampered state refused, a denied consent refused, an unknown
identity refused BY THE SERVER (not just absent from the picker), a same-site
next= surviving and an off-site one ignored, and OKTA_IDENTITY_CLAIM genuinely
working under a non-default claim name. 22/22.

One thing this could not verify in this environment: url_state_check.py and
browser_check.py both need a headless Edge/Chrome via cdp.py, and this sandbox
has neither installed and no way to install one (no sudo). Confirmed the failure
is the tests' own designed-for exit 2 ("no headless-capable browser found; set
WP_BROWSER"), not a crash, and separately confirmed start_server() itself boots
cleanly with the fake wired in - health check, the picker page rendering with
the seeded identities, login.html all responding correctly - so the only gap is
the DOM-level click-through, not the server-side mechanism url_state_check
exercises (which okta_auth_check.py covers directly via HTTP instead).

wave-10.md's T10.7 bullet records the shape of what got built and the 22/22
result.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Matt Mabrey
2026-09-03 12:11:24 -07:00
parent 72b10283fc
commit 290c9b078c
7 changed files with 662 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

62
tests/url_state_check.py
View File

@@ -7,11 +7,13 @@ the suite, so no work package had an address. This checks the promise those emai
will rest on.
1. a URL identifying a work package opens that work package
2. the same URL works for a SIGNED-OUT user, via login, landing on the target
— SKIPPED as of T10.4: local login is gone (D15/D16), and the redirect-
through-Okta replacement doesn't exist until T10.5 rebuilds login.html.
Re-test this once that lands. Signing in via a minted token stands in as
setup only, so scenarios 3-6 below still get a signed-in page to run on.
2. the same URL works for a SIGNED-OUT user, via the real Okta sign-in round
trip (T10.7's fake provider stands in for Okta itself — see
server/okta_fake.py — but the app's own login.html, the redirect to
/api/auth/okta/login, the state round trip through SessionMiddleware, and
okta_callback()'s handling of ?next= are all real, unmodified code).
Landing on the requested target, not the home page, doubles as setup for
scenarios 3-6 below.
3. refresh preserves project, package, tab and view
4. Back and Forward move through states without a reload or a broken view
5. the URL survives being copied to a second browsing context
@@ -172,9 +174,7 @@ def main():
finally:
page2.close()
print("\n2. the same URL works for a signed-out user, via login")
print(" SKIPPED: local login is gone (D15/D16); the Okta-redirect replacement")
print(" doesn't exist until T10.5. Re-test the next= round trip once it lands.")
print("\n2. the same URL works for a signed-out user, via the real Okta round trip")
page.clear_cookies()
page.goto(deep)
settle(page, 1.6)
@@ -183,14 +183,44 @@ def main():
nxt = page.eval("new URLSearchParams(location.search).get('next')||''")
chk("...carrying the requested target, package id and all",
"wp-creation-index.html" in nxt and "wp=wpA1" in nxt, "next=%r" % nxt)
# Setup only for scenarios 3-6 below, NOT a re-test of "signing in continues
# to the requested page" — that promise is specific to the login FORM this
# task removed, and can't be honestly re-proven until T10.5 rebuilds it as an
# Okta redirect. A minted-token cookie gets `page` to the same signed-in,
# on-target state those later scenarios need, without claiming to have
# exercised the (currently nonexistent) sign-in flow itself.
page.set_cookie("wp_session", tok["root"])
page.goto(deep)
# Drive the actual button, not a shortcut to it — its href already
# carries ?next= (login.js's safeNext()); this is the same click a
# person makes.
signin_href = page.eval(
"(document.getElementById('okta-signin')||{}).getAttribute('href')||''")
chk("the sign-in link itself carries ?next=", "next=" in signin_href, signin_href)
page.goto(base + signin_href)
for _ in range(30):
if "_fake_provider" in page.eval("location.href"):
break
time.sleep(0.3)
chk("the app hands off to the (fake) Okta provider",
"_fake_provider" in page.eval("location.href"), page.eval("location.href"))
# The fake provider's own picker page — a real page, not a shortcut.
# See server/okta_fake.py: only the network-touching Authlib calls are
# faked, not app.py's own login/callback/JIT/guard code.
identity_href = page.eval(
"(document.getElementById('okta-fake-identity-root')||{}).getAttribute('href')||''")
chk("the fake provider offers the seeded 'root' identity", bool(identity_href),
page.eval("document.body.innerHTML"))
page.goto(base + identity_href)
for _ in range(30):
href = page.eval("location.href")
if "login.html" not in href and "_fake_provider" not in href:
break
time.sleep(0.3)
settle(page, 1.0)
# NOT `"wp-creation-index.html" in location.href` alone — that string
# is in the ?next= parameter too, so this would pass while still
# sitting on login.html with the sign-in rejected (the same mistake
# D13/T10.7's LDAP predecessor caught and fixed here). Assert we
# actually LEFT the login page.
href = page.eval("location.href")
chk("signing in continues to the requested page, not the home page",
"login.html" not in href and "wp-creation-index.html" in href
and "wp=wpA1" in href, href)
for _ in range(30):
if page.eval("!!window.wpCreatorReady"):
break