v2.0rc2

[mkalioby]

v2.0rc2

• Breaking Change: Moved templates to passkeys folder and renamed the templates. thanks to @ganiyevuz and @smark-1
  • PassKeys.html -> passkeys/manage.html
  • PassKeys_base.html -> passkeys/base.html
  • check_passkeys.js -> passkeys/check.js
  • passkeys.js -> passkeys/passkeys.js
  • modal.html -> passkeys/modal.html
• Dropped Support for django-2.0, django-2.1, django-4.0, django-4.1, django-5.0, django-5.1, but django 2.2, 3.2.
• New: DRF API module (passkeys.api) — REST endpoints for passkey registration, authentication, and management
• New: Pluggable token backend — auto-detects SimpleJWT, DRF TokenAuth, or session-based auth
• New: Service layer (passkeys.api.service) — session-independent FIDO2 logic with signed state tokens
• New: Optional install via pip install django-passkeys[drf] or pip install django-passkeys[drf-jwt]
• Added: Support for Google new WebAuthn immediate mediation API (with allow/disallow password login) for Chromium Browser. for more details check Google's announcement.
• Fix: add @login required to passkey registration views. thanks to @rafaelurbeno for reporting the issue.
• New: Add docs and hosted on readthedocs.io

---

This discussion was created from the release v2.0rc2.

[mkalioby]

@mahmoodnasr can you give this a try and let us know

[mahmoodnasr]

PR #66 — V2.0 Code Review

This is a substantial release: new DRF API layer, template renames, immediate mediation support, new service/token architecture, and many JS files. Here's everything I found, ordered by severity.

---

CRITICAL

1. JavaScript SyntaxError — Duplicate else block in check.js

File: passkeys/templates/passkeys/check.js (patch around lines 8-17)

The patch adds a second else block to the same if, which is a JavaScript SyntaxError and will break all pages that include this template.

if (available) {
  success_func();
}
else{                  // ← NEW (added by PR)
    fail_func();
}

else{                  // ← ORIGINAL (already existed)
    fail_func();
}

Fix: Remove the duplicate else block. Keep only one.

---

2. JavaScript Typos — getElementById misspelled 3 times in static JS

File: passkeys/static/passkeys/js/passkeys.js, lines 96-98

document.getElementbyId("username").value = assertion.id;     // lowercase 'b'
document.getElementbyId("password").value = assertion.password; // lowercase 'b'
document.getElmentbyId(window.loginForm).submit();            // missing 'e' + lowercase 'b'

All three will throw TypeError: document.getElementbyId is not a function at runtime. The template version (passkeys/templates/passkeys/passkeys.js) has the correct spelling, but this static file (used by the DRF API flow) is broken.

Fix: Change all three to document.getElementById(...).

---

3. Security — Open Redirect in loginView

File: example/test_app/auth.py, lines ~14-16

if request.POST.get("next",""):
    return redirect(request.POST["next"])

The next parameter from POST data is used directly in redirect() without validation. An attacker can craft a login form that redirects users to https://evil.com/phishing after successful authentication.

Severity: Critical (this is the example app users will copy)

Fix: Validate the next URL is relative or use Django's url_has_allowed_host_and_scheme:

from django.utils.http import url_has_allowed_host_and_scheme

next_url = request.POST.get("next", "")
if next_url and url_has_allowed_host_and_scheme(next_url, allowed_hosts={request.get_host()}):
    return redirect(next_url)
return redirect('template')

---

HIGH

4. Bug — tryLogin() always submits the form

Files: Both passkeys/static/passkeys/js/passkeys.js (line 26-28) and passkeys/templates/passkeys/passkeys.js (line 31-32)

if (usernamefield.value != "" && passwordfield.value != "") {
}
document.getElementById(formid).submit();

The if block is empty {}. The submit() call always executes regardless of input. After submit(), the page navigates away so the immediate mediation check below it never runs. The if/else logic after it is dead code.

Fix: The submit should probably be inside the if, and the else should handle the immediate mediation or focus logic.

---

5. Security — Broad exception swallowing in service layer

File: passkeys/api/service.py, lines 49-53 and 83-86

# reg_complete_service
except Exception:
    raise PasskeyVerificationError("Passkey verification failed, please try again")

# auth_complete_service
except Exception:
    raise PasskeyVerificationError("Passkey authentication failed")

Bare except Exception catches everything: database connection errors, MemoryError, AttributeError, coding bugs. All get turned into "verification failed." This will make production debugging a nightmare.

Fix: Catch specific exceptions. At minimum, log the original exception:

except Exception:
    logger.exception("Passkey registration verification failed")
    raise PasskeyVerificationError("Passkey verification failed, please try again")

The logging line is even commented out in the code (line 53) — uncomment it.

---

6. Bug — complete_registration mutates the input credential_data dict

File: passkeys/webauthn.py, line 104

name = credential_data.pop("key_name", '') or platform

.pop() modifies the dict in place. When called from the API service layer (reg_complete_service), the caller has already set credential['key_name'] = key_name and then passes it to complete_registration. The server.register_complete(state, response=credential_data) is called before the pop, so key_name is passed to fido2 as part of the response data. This could cause fido2 to fail on unexpected fields.

Fix: Use .get() and del separately, or copy the dict:

name = credential_data.get("key_name", '') or platform
credential_data.pop("key_name", None)  # clean up after extraction

Or better, pass key_name as a separate parameter rather than stuffing it into credential_data.

---

7. Performance — Double DB query in complete_authentication

File: passkeys/webauthn.py, lines 122-127

keys = UserPasskey.objects.filter(credential_id=credential_id, enabled=1)
if not keys.exists():
    return None
key = keys[0]

keys.exists() hits the database once. keys[0] hits it again. Then key.user triggers a third query (no select_related).

Fix:

key = UserPasskey.objects.filter(
    credential_id=credential_id, enabled=True
).select_related('user').first()
if key is None:
    return None

---

MEDIUM

8. Security — No rate limiting on authentication endpoints

File: passkeys/api/views.py

AuthenticateOptionsAPIView and AuthenticateVerifyAPIView both use AllowAny with no rate limiting. While the state token expires in 5 minutes, an attacker can request unlimited tokens and attempt unlimited verifications.

Fix: Add DRF throttling:

from rest_framework.throttling import AnonRateThrottle

class AuthenticateOptionsAPIView(GenericAPIView):
    throttle_classes = [AnonRateThrottle]
    ...

Or document that users should configure throttling in their REST_FRAMEWORK settings.

---

9. Security — Potential open redirect in helpers.py

File: passkeys/helpers.py, lines 9-10

def get_redirection_url(request, default="/"):
    return HttpResponseRedirect(
        request.META.get('HTTP_REFERER', default).replace(
            request.META.get("HTTP_ORIGIN", ""), ""))

HTTP_REFERER is user-controlled. If an attacker sets Referer: https://evil.com/steal-creds and Origin doesn't match, the redirect goes to an external domain.

Fix: Validate the redirect URL against allowed hosts.

---

10. Maintainability — Massive JS duplication

Files: passkeys/static/passkeys/js/passkeys.js (135 lines) vs passkeys/templates/passkeys/passkeys.js (149 lines)

These are near-identical copies of the same logic. The static version has the getElementById typos (issue #2), while the template version doesn't. Over time these will diverge further.

Fix: Extract shared logic into the static JS file and have the template just set config variables and include the static file.

---

11. Bug — enabled=1 instead of enabled=True

File: passkeys/webauthn.py, line 122

keys = UserPasskey.objects.filter(credential_id=credential_id, enabled=1)

While 1 works as True in SQLite and PostgreSQL, it's not idiomatic Django and could behave differently on some backends.

Fix: Use enabled=True.

---

12. Bug — _session_token_backend assumes session middleware exists

File: passkeys/api/token_backends.py, lines 10-13

def _session_token_backend(user, request):
    from django.contrib.auth import login as auth_login
    auth_login(request, user, backend='passkeys.backend.PasskeyModelBackend')
    return {'token_type': 'session'}

If a DRF client uses token auth without session middleware, auth_login will fail because request.session doesn't exist. This is the fallback backend, so it could be triggered unexpectedly when neither JWT nor DRF Token is installed.

Fix: Check for session availability or catch the AttributeError:

if not hasattr(request, 'session'):
    raise ImproperlyConfigured(
        "Session middleware required for session token backend. "
        "Install django-passkeys[drf] for token-based auth."
    )

---

LOW

13. exception wrapping destroys traceback

File: passkeys/webauthn.py, lines 137-138

except Exception as excep:
    raise Exception(excep)

This wraps the original exception in a new generic Exception, destroying the stack trace and type information. Should be raise (re-raise) or raise ... from excep.

---

14. Global variable pollution in JS

Files: Multiple JS files

Variables like key_name, key_info, sendData, data, assertion, options, status, html, key, i are used without let/const/var, polluting the global scope. This can cause subtle conflicts with other scripts.

---

15. manage view uses relative redirect path

File: example/test_app/views.py, lines 19-21

def manage(request):
    if not request.user.is_authenticated:
        return HttpResponseRedirect("../login/")

Uses ../login/ which is fragile if URL structure changes. Should use reverse() or @login_required.

---

16. Missing trailing newlines

Files: passkeys/api/views.py, passkeys/api/service.py, passkeys/api/serializers.py, passkeys/webauthn.py, passkeys/helpers.py, and several others.

Multiple files end without a trailing newline (seen as \ No newline at end of file). Minor, but non-POSIX-compliant and noisy in diffs.

---

17. Coverage dropped from 100% to 93.32%

File: coverage.svg

6.7% coverage drop. Many new code paths are marked # pragma: no cover. Worth adding tests for the new static JS files' server-side rendering and edge cases in the token backends.

---

Summary Table

#	Severity	File	Issue
1	Critical	check.js template	Duplicate else block — SyntaxError
2	Critical	passkeys.js static	getElementById misspelled 3x — TypeError
3	Critical	auth.py (example)	Open redirect via unvalidated next param
4	High	Both passkeys.js	tryLogin() always submits — dead code after
5	High	service.py	Bare except Exception hides real errors
6	High	webauthn.py	.pop() mutates input dict before fido2 processes it
7	High	webauthn.py	Double DB query + missing select_related
8	Medium	views.py (API)	No rate limiting on public auth endpoints
9	Medium	helpers.py	Potential open redirect via HTTP_REFERER
10	Medium	JS files	Near-identical 135-line duplication
11	Medium	webauthn.py	enabled=1 instead of enabled=True
12	Medium	token_backends.py	Session fallback fails without session middleware
13	Low	webauthn.py	raise Exception(excep) destroys traceback
14	Low	JS files	Global variable pollution (no let/const)
15	Low	views.py (example)	Relative redirect path is fragile
16	Low	Multiple	Missing trailing newlines
17	Low	coverage	Dropped from 100% to 93.32%

Bottom line: Issues #1, #2, and #3 are ship-blockers. Issues #4-#7 should be fixed before release. The rest can be addressed in a follow-up, but I'd push back on merging until at least the Critical and High items are resolved.

[mkalioby]

Thanks
fixed, please recheck.

[mkalioby]

Uploaded v2.0rc3