We've been running Hyperproof in a Kubernetes environment for compliance tracking across multiple teams, and we've hit a persistent and frankly bizarre authentication issue that's wasting engineering time. Our setup uses SAML SSO via Okta, and while Chrome and Edge browsers authenticate and redirect back to Hyperproof seamlessly, Firefox consistently gets stuck in a login loop. The redirect from the IdP back to the Hyperproof callback URL seems to complete, but then the page reloads and kicks the user back to the Okta login screen. This is not a trivial problem—it blocks an entire team from accessing the platform based on their browser choice.
I've ruled out the obvious culprits: browser cache/cookies, basic extensions (tested in Safe Mode), and our IdP configuration (since Chrome works). The behavior points to something specific in how Firefox handles cookies, redirects, or the session storage during the SAML handshake within Hyperproof's embedded authentication flow.
Here's a high-level view of our ingress and session configuration, as the issue might be environmental:
```yaml
# Relevant Ingress snippet for the Hyperproof app
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: hyperproof-ingress
annotations:
nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "route"
nginx.ingress.kubernetes.io/session-cookie-samesite: "Lax"
nginx.ingress.kubernetes.io/proxy-body-size: "10m"
spec:
ingressClassName: nginx
rules:
- host: compliance.ourcompany.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: hyperproof-proxy
port:
number: 8443
```
**Key questions for the community:**
* Has anyone encountered and resolved a browser-specific SSO loop with Hyperproof, particularly Firefox?
* Are there known issues with Firefox's default cookie policies (e.g., `SameSite=Lax` vs `Strict`) or Enhanced Tracking Protection that break the Hyperproof SSO flow?
* Does Hyperproof's backend have any known dependencies on specific browser behaviors for session management? The support response so far has been generic "clear your cache" which is insufficient.
* If you run Hyperproof behind a reverse proxy (nginx, ALB, etc.), did you need any special configuration for Firefox?
The lack of clear logging on the Hyperproof side during authentication makes this painful to debug. I'm looking for concrete configuration changes, documented pitfalls, or a confirmed bug. Browser-specific issues in a core flow like authentication are a major red flag for scalability and supportability.
– A
Show me the benchmarks.
Finish posting your ingress config, but I'll bet money your problem is SameSite cookie handling in Firefox. Firefox treats `SameSite=Lax` differently on POST redirects during SAML flows.
Check these in your ingress annotations:
```yaml
nginx.ingress.kubernetes.io/proxy-cookie-path: "Path=/; Secure; SameSite=None"
nginx.ingress.kubernetes.io/configuration-snippet: |
proxy_cookie_flags ~ secure samesite=none;
```
If you're not using nginx ingress, same concept applies for whatever gateway you have.
slow pipelines make me cranky