Purpose: Record the important integration steps for connecting DjangoPlay to the AuthX identity/authentication service, including diagnostics, fixes, and validation results.

1. AuthX Service Connectivity

Problem

The DjangoPlay client is configured to use:

python

AUTHX_BASE_URL
AUTHX_SERVICE_TOKEN
AUTHX_TIMEOUT

The AuthX client ultimately calls:

text

POST /internal/identities

Debugging

Inspect the installed DjangoPlay client:

bash

python - <<'PY'
import inspect
from authx_client import AuthXClient

print("FILE:", inspect.getfile(AuthXClient))

print("\n--- __init__ ---")
print(inspect.getsource(AuthXClient.__init__))

print("\n--- create_identity ---")
print(inspect.getsource(AuthXClient.create_identity))
PY

Confirmed:

python

self._base_url = getattr(settings, "AUTHX_BASE_URL", "http://authx:8100")
self._service_token = getattr(settings, "AUTHX_SERVICE_TOKEN", "")
self._timeout = getattr(settings, "AUTHX_TIMEOUT", 10.0)

and:

python

response = client.post(
    f"{self._base_url}/internal/identities",
    json={...},
    headers=self._headers,
)

Service Token Validation

Check the token inside the AuthX container:

bash

docker exec authx-identity-authx-1 sh -lc '
python - <<'PY'
import os

token = os.getenv("AUTHX_SERVICE_TOKEN", "")

print("configured:", bool(token))
print("length:", len(token))
print("repr prefix/suffix:", repr(token[:8]), repr(token[-8:]))
print("has leading whitespace:", token != token.lstrip())
print("has trailing whitespace:", token != token.rstrip())
PY
'

Result:

text

configured: True
length: 96
has leading whitespace: False
has trailing whitespace: False

Result

The service token is correctly configured.

2. AuthX Internal API Authentication / Routing

Problem

You need to verify that the internal AuthX API is reachable and that the service-token authentication path is functioning.

Debug Command

Test an internal identity endpoint with an intentionally invalid UUID:

bash

curl -i \
  -H "X-Service-Token: ***" \
  http://localhost:8100/internal/identities/nonexistent

Result

text

HTTP/1.1 422 Unprocessable Entity

with:

json

{
  "detail": [
    {
      "type": "uuid_parsing",
      "loc": ["path", "identity_id"],
      "msg": "Input should be a valid UUID"
    }
  ]
}

Interpretation

This is actually a positive result.

The request successfully reached the AuthX application and routing layer. The 422 is generated by FastAPI because "nonexistent" is not a valid UUID.

Result

AuthX connectivity and internal endpoint routing confirmed.

3. Password Hashing Failure

Problem

During identity creation, AuthX failed while hashing the password.

The important error is :

text

(trapped) error reading bcrypt version
AttributeError: module 'bcrypt' has no attribute '__about__'

followed by:

text

ValueError: password cannot be longer than 72 bytes,
truncate manually if necessary

The stack trace showed:

text

IdentityService.create()
    ↓
hash_password()
    ↓
pwd_context.hash()
    ↓
Passlib bcrypt backend
    ↓
bcrypt

Root Cause

The installed bcrypt version is incompatible with the way the current passlib bcrypt backend detects/uses the bcrypt package.

This is identified as a dependency compatibility issue, separate from the later JWT problem.

Important Observation

This problem occurs during password hashing / identity creation, not during JWT issuance.

4. Identity Creation Confirmed

Actual Result

The account is successfully created in AuthX.

This established that:

text

DjangoPlay
    ↓
AuthXClient
    ↓
AuthX /internal/identities
    ↓
Identity creation
    ↓
Password hashing
    ↓
Database

is functioning.

Problem

After successful signup, attempting to log in from DjangoPlay displays:

text

No account found with this email or username.

Please use correct username/email or create a new account.

Initially this appears to indicate an identity lookup/authentication failure.

Debugging

AuthX logs shows a different failure.

The important part of the traceback is :

text

IdentityService.authenticate(...)
    ↓
_issue_tokens(identity)
    ↓
create_access_token(...)
    ↓
jwt.encode(...)
    ↓
JWSError

Specifically:

text

jose.exceptions.JWSError:
Unable to load PEM file
...
InvalidData(Invalid symbol 92, offset 64.)

Interpretation

The identity had already been authenticated.

The failure occurrs afterward while AuthX attempts to issue the access token.

Therefore the DjangoPlay message:

text

No account found with this email or username.

is misleading for this particular failure.

The actual problem is JWT signing.

6. JWT PEM Configuration Failure

Problem

AuthX could not load the configured RSA private/public keys.

The error is :

text

Unable to load PEM file
InvalidData(Invalid symbol 92, offset 64.)

The value 92 corresponds to:

text

ASCII backslash.

Initial Hypothesis

The first suspicion is that .env contained literal:

text

\n

instead of actual newlines.

AuthX already had a validator intended to handle this:

python

@field_validator("jwt_private_key", "jwt_public_key", mode="before")
@classmethod
def normalize_pem(cls, value: str) -> str:
    if not value:
        return value

    return value.replace("\\n", "\n").strip()

Therefore we do not need to add another normalization mechanism.

7. Correct Settings Module Identified

The actual configuration API is :

python

@lru_cache
def get_settings() -> Settings:
    return Settings()

Therefore the correct diagnostic import is :

python

from authx.core.settings import get_settings

8. Initial PEM Validation

Inspect the private key loaded by Pydantic:

bash

docker exec authx-identity-authx-1 sh -lc '
python - <<'"'"'PY'"'"'
from authx.core.settings import get_settings

s = get_settings()
key = s.jwt_private_key

print("type:", type(key))
print("length:", len(key))
print("literal_backslash_n:", "\\n" in key)
print("real_newline:", "\n" in key)
print("starts:", repr(key[:40]))
print("ends:", repr(key[-40:]))
PY
'

The loaded value had:

text

real newline: True

and no literal \n escape sequence.

This initially suggested that newline normalization is working correctly.

9. Direct Cryptography Validation

Test the actual PEM rather than relying only on string inspection.

Private Key

bash

docker exec authx-identity-authx-1 sh -lc '
python - <<'"'"'PY'"'"'
from authx.core.settings import get_settings
from cryptography.hazmat.primitives.serialization import load_pem_private_key

s = get_settings()
key = s.jwt_private_key

try:
    load_pem_private_key(key.encode(), password=None)
    print("PRIVATE KEY: VALID")
except Exception as e:
    print("PRIVATE KEY: INVALID")
    print(type(e).__name__, str(e))
PY
'

Result:

text

PRIVATE KEY: INVALID
ValueError Unable to load PEM file
InvalidData(Invalid symbol 92, offset 64.)

Public Key

bash

docker exec authx-identity-authx-1 sh -lc '
python - <<'"'"'PY'"'"'
from authx.core.settings import get_settings
from cryptography.hazmat.primitives.serialization import load_pem_public_key

s = get_settings()
key = s.jwt_public_key

try:
    load_pem_public_key(key.encode())
    print("PUBLIC KEY: VALID")
except Exception as e:
    print("PUBLIC KEY: INVALID")
    print(type(e).__name__, str(e))
PY
'

Result:

text

PUBLIC KEY: INVALID
ValueError Unable to load PEM file
InvalidData(Invalid symbol 92, offset 64.)

Result

The keys have correct PEM framing/newlines but contains invalid characters inside the Base64 body.

10. Locate the Corrupted Characters

Search the loaded PEM values for backslashes.

The private key contained many unexpected backslashes:

text

BACKSLASH at: 92
...
BACKSLASH at: 157
...
BACKSLASH at: 222
...

Example:

text

...EjIvI\7cegv/3...

The public key also contained invalid backslashes:

text

...HoL/9\xB4...

These characters cannot occur in a valid PEM Base64 body.

11. Confirm `.env` Was the Source

You inspected the actual AuthX .env file:

bash

docker exec authx-identity-authx-1 sh -lc '
python - <<'PY'
from pathlib import Path

p = Path("/app/.env")

print("exists:", p.exists())

if p.exists():
    text = p.read_text()

    for name in ("JWT_PRIVATE_KEY", "JWT_PUBLIC_KEY"):
        for line in text.splitlines():
            if line.startswith(name + "="):
                value = line.split("=", 1)[1]
                print("\n", name)
                print("raw line length:", len(value))
                print("backslashes:", value.count("\\"))
                print("first 150:", repr(value[:150]))
                break
PY
'

Result:

text

JWT_PRIVATE_KEY
raw line length: 1707
backslashes: 27

JWT_PUBLIC_KEY
raw line length: 454
backslashes: 8

Distinguish legitimate newline escapes from invalid backslashes:

bash

python - <<'PY'
from pathlib import Path

text = Path(".env").read_text()

for name in ("JWT_PRIVATE_KEY", "JWT_PUBLIC_KEY"):
    for line in text.splitlines():
        if line.startswith(name + "="):
            value = line.split("=", 1)[1]

            print("\n" + name)
            print("backslashes:", value.count("\\"))
            print("newline escapes:", value.count("\\n"))
            print(
                "other backslashes:",
                value.count("\\") - value.count("\\n")
            )
PY

Result:

text

JWT_PRIVATE_KEY
backslashes: 27
newline escapes: 2
other backslashes: 25

JWT_PUBLIC_KEY
backslashes: 8
newline escapes: 2
other backslashes: 6

Root Cause Confirmed

The RSA keys stored in .env are corrupted.

The problem is not the Pydantic validator.

The .env contained additional backslashes embedded inside the Base64 key material.

12. RSA Key Pair Regenerated

The correct solution is to replace the corrupted RSA key pair rather than attempting to remove the invalid characters.

Generate a new private key:

bash

openssl genrsa -out jwt_private.pem 2048

Generate the matching public key:

bash

openssl rsa \
  -in jwt_private.pem \
  -pubout \
  -out jwt_public.pem

Validate the private key:

bash

openssl rsa \
  -in jwt_private.pem \
  -check \
  -noout

Expected:

text

RSA key ok

13. Generate Safe `.env` Values

Rather than manually copying PEM content, convert the PEM files into the escaped format expected by .env:

bash

python - <<'PY'
from pathlib import Path

def env_pem(path):
    return Path(path).read_text().strip().replace("\n", "\\n")

print(f'JWT_PRIVATE_KEY="{env_pem("jwt_private.pem")}"')
print(f'JWT_PUBLIC_KEY="{env_pem("jwt_public.pem")}"')
PY

The generated values are placed into AuthX .env.

14. Validate `.env` Before Restart

Run:

bash

python - <<'PY'
from pathlib import Path

text = Path(".env").read_text()

for name in ("JWT_PRIVATE_KEY", "JWT_PUBLIC_KEY"):
    for line in text.splitlines():
        if line.startswith(name + "="):
            value = line.split("=", 1)[1]

            print("\n" + name)
            print("backslashes:", value.count("\\"))
            print("newline escapes:", value.count("\\n"))
            print(
                "other backslashes:",
                value.count("\\") - value.count("\\n")
            )
PY

Expected result:

text

JWT_PRIVATE_KEY
backslashes: 2
newline escapes: 2
other backslashes: 0

JWT_PUBLIC_KEY
backslashes: 2
newline escapes: 2
other backslashes: 0

This confirms that the only backslashes are the two intended \n separators.

15. Rebuild and Recreate AuthX

After updating .env:

bash

docker compose build authx

Then:

bash

docker compose up -d --force-recreate authx

DjangoPlay is also restarted as required:

bash

docker compose up -d --force-recreate djangoplay

16. Validate PEMs Inside the Running Container

Before testing login, validate the actual values loaded by AuthX:

bash

docker exec authx-identity-authx-1 sh -lc '
python - <<'"'"'PY'"'"'
from authx.core.settings import get_settings
from cryptography.hazmat.primitives.serialization import (
    load_pem_private_key,
    load_pem_public_key,
)

s = get_settings()

for name, loader, value in [
    ("PRIVATE", load_pem_private_key, s.jwt_private_key),
    ("PUBLIC", load_pem_public_key, s.jwt_public_key),
]:
    print(name)
    print("  length:", len(value))
    print("  literal \\\\n:", "\\\\n" in value)
    print("  real newline:", "\n" in value)

    try:
        if name == "PRIVATE":
            loader(value.encode(), password=None)
        else:
            loader(value.encode())

        print("  PEM: VALID")
    except Exception as e:
        print("  PEM: INVALID")
        print(" ", type(e).__name__, str(e))
PY
'

Validation Result

Both RSA keys are successfully loaded as valid PEM keys.

The login flow is tested again after recreating the containers.

The previous failure:

text

jose.exceptions.JWSError:
Unable to load PEM file
InvalidData(Invalid symbol 92, offset 64.)

is resolved.

The AuthX flow now successfully reaches JWT creation using the valid RSA private key.

Final Flow

text

DjangoPlay
    │
    │ login credentials
    ▼
AuthX
    │
    ├── find identity
    ├── verify password
    ├── authenticate identity
    │
    ▼
Issue JWT
    │
    ├── RSA private key
    ├── RS256
    │
    ▼
Access / Refresh Tokens
    │
    ▼
DjangoPlay

18. Current Status

Area	Status
DjangoPlay → AuthX connectivity	✅ Working
AuthX service token	✅ Valid
Internal API routing	✅ Validated
Identity creation	✅ Working
Password hashing	✅ Working
Account creation	✅ Working
Login identity authentication	✅ Reached successfully
JWT private key	✅ Fixed
JWT public key	✅ Fixed
PEM validation	✅ Passing
JWT signing	✅ Fixed
Previous `Invalid symbol 92` error	✅ Resolved

Key Lessons

1. HTTP 422 can confirm connectivity

The test:

bash

curl -i \
  -H "X-Service-Token: ***" \
  http://localhost:8100/internal/identities/nonexistent

returns 422 because the UUID is invalid. This proved the request is reaching FastAPI successfully.

2. Do not trust the frontend error message alone

The DjangoPlay message:

text

No account found with this email or username.

is misleading.

The AuthX traceback shows that authentication had already succeeded and the failure happened during:

text

_issue_tokens()
    ↓
create_access_token()
    ↓
jwt.encode()

3. Validate cryptographic material directly

String checks such as:

text

real newline: True

are insufficient.

The decisive validation is :

python

load_pem_private_key(...)
load_pem_public_key(...)

4. Only `\n` escapes are valid in the `.env` representation

For the current configuration:

text

2 backslashes = 2 newline escapes
other backslashes = 0

is the expected state.

Unexpected backslashes inside the Base64 body indicate corrupted key material.

5. Keep the PEM normalization validator

The existing:

python

return value.replace("\\n", "\n").strip()

is correct for the .env representation being used.

The problem is the corrupted RSA key values, not the normalization code.

AuthX ↔ DjangoPlay Integration

#1. AuthX Service Connectivity

#Problem

#Debugging

#Service Token Validation

#Result

2. AuthX Internal API Authentication / Routing

#Problem

#Debug Command

#Result

#Interpretation

#Result

3. Password Hashing Failure

#Problem

#Root Cause

#Important Observation

4. Identity Creation Confirmed

#Actual Result

5. Login Reported "No Account Found"

#Problem

#Debugging

#Interpretation

6. JWT PEM Configuration Failure

#Problem

#Initial Hypothesis

7. Correct Settings Module Identified

8. Initial PEM Validation

9. Direct Cryptography Validation

#Private Key

#Public Key

#Result

10. Locate the Corrupted Characters

11. Confirm .env Was the Source

#Root Cause Confirmed

12. RSA Key Pair Regenerated

13. Generate Safe .env Values

14. Validate .env Before Restart

15. Rebuild and Recreate AuthX

16. Validate PEMs Inside the Running Container

#Validation Result

17. Final Login Validation

#Final Flow

18. Current Status

#Key Lessons

#1. HTTP 422 can confirm connectivity

#2. Do not trust the frontend error message alone

#3. Validate cryptographic material directly

#4. Only \n escapes are valid in the .env representation

#5. Keep the PEM normalization validator

1. AuthX Service Connectivity

Problem

Debugging

Service Token Validation

Result

Problem

Debug Command

Result

Interpretation

Result

Problem

Root Cause

Important Observation

Actual Result

Problem

Debugging

Interpretation

Problem

Initial Hypothesis

Private Key

Public Key

Result

11. Confirm `.env` Was the Source

Root Cause Confirmed

13. Generate Safe `.env` Values

14. Validate `.env` Before Restart

Validation Result

Final Flow

Key Lessons

1. HTTP 422 can confirm connectivity

2. Do not trust the frontend error message alone

3. Validate cryptographic material directly

4. Only `\n` escapes are valid in the `.env` representation

5. Keep the PEM normalization validator