Dashboard: Safari standalone web app (iOS home-screen web app) does not AutoFill or save the admin token

[x3M3x]

Client or integration

OpenCodex dashboard

Area

Dashboard

Summary

On iOS, the dashboard admin-token sign-in is never offered password AutoFill when the dashboard is installed as a standalone web app (Safari → Share → Add to Home Screen). Safari in the regular browser tab does offer AutoFill/Save for the same dialog; only the standalone home-screen web app does not. The admin token is long and random, so without AutoFill the only option is manual copy/paste on every sign-in.

The dialog already follows the standard shape (gui/src/admin-token-dialog.ts): a real <form method="post" action="..."> with a type="text" autocomplete="username" field and a type="password" name="password" autocomplete="current-password" field, plus a submit button. Submission is a normal submit event handler that calls preventDefault() and verifies the token via fetch. Despite that, the iOS standalone (WKWebView home-screen) context never shows the QuickType password suggestion bar for the field and never offers to save the credential, while the same page in Safari proper does.

Expected: the admin token field offers iOS password AutoFill (QuickType key / saved credentials) in the standalone web app, and Safari offers to save the credential after a successful sign-in.

Reproduction

1. Serve the dashboard on a LAN/Tailscale URL (ocx start).
2. In iOS Safari, open the dashboard and sign in with the admin token — AutoFill suggestions and the save-password prompt appear in the browser.
3. In iOS Safari, use Share → Add to Home Screen, then launch the dashboard from the home-screen web app.
4. Focus the admin token field: no password AutoFill suggestion bar appears, and after a successful sign-in Safari never offers to save the credential.

Version

2.48.0

Operating system

Server: Windows 11; client: iPhone, iOS (Safari standalone web app via Add to Home Screen)

Logs or error output

None — no server-side error; sign-in succeeds when the token is entered manually. The problem is purely that iOS standalone-mode Safari does not treat the field as a login credential field.

Screenshots and supporting files

Screenshot of the standalone web app sign-in showing the token field without any AutoFill suggestion bar (attached to the thread; can be re-attached on request).

Redacted configuration

Not provider/config specific — affects the dashboard sign-in dialog itself.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[lidge-jun]

리뷰 · 우선순위 48 / 80

설명

이 이슈는 OpenCodex 대시보드를 iOS Safari에서 공유 → 홈 화면에 추가로 연 뒤(스탠드얼론 웹앱 / WKWebView 홈스크린 모드) 관리자 토큰 로그인 칸에 비밀번호 AutoFill(QuickType)과 저장 제안이 안 뜨는 문제입니다. 같은 URL을 일반 Safari 탭에서 열면 AutoFill·저장이 되고, 홈스크린 앱에서만 안 됩니다. 서버 쪽 401/검증 실패가 아니라, 긴 랜덤 admin token을 매번 손으로 붙여 넣어야 하는 UX 구멍입니다.

지금 dev HEAD(627274b8f, package 2.56.0) 기준으로 보면, 로그인 UI는 이미 비밀번호 관리자를 의식해서 짜여 있습니다. gui/src/admin-token-dialog.ts의 promptForAdminToken은 실제 <form method="post">에 autocomplete="username" 읽기 전용 계정칸(값은 고정 문자열 OpenCodex)과 type="password" name="password" autocomplete="current-password" 토큰칸, submit 버튼을 만듭니다. 주석에도 브라우저/비밀번호 관리자가 저장·자동완성을 제안할 수 있게 진짜 로그인 폼 모양을 쓴다고 적혀 있고, OpenCodex 쪽은 제출된 토큰을 메모리에만 두고 영속화는 브라우저에 맡깁니다.

제출 경로는 일반 폼 네비게이션이 아닙니다. submit에서 preventDefault()한 뒤 verifyToken(실제로는 gui/src/api.ts의 verifyAdminToken → /api/settings에 토큰을 실어 검증)으로 fetch합니다. 수락되면 resolveTokenAfter401이 state.session.token에 넣고 이후 API에 X-OpenCodex-API-Key로 붙입니다. 즉 “페이지가 POST로 넘어가서 서버가 Set-Cookie 하는 고전 로그인”이 아니라 SPA 다이얼로그 + AJAX 검증입니다. Safari 탭에서는 이 모양만으로도 AutoFill이 되는 경우가 많지만, iOS 홈스크린(디스플레이 모드가 사실상 스탠드얼론)에서는 Password AutoFill 휴리스틱이 훨씬 빡세고, AJAX 성공 뒤에 저장 제안이 안 나오는 일이 흔합니다.

셸도 스탠드얼론을 따로 선언하지 않습니다. gui/index.html에는 viewport·테마 스크립트만 있고 apple-mobile-web-app-capable / mobile-web-app-capable 메타도, manifest.webmanifest(display: standalone)도 없습니다. 사용자가 Safari에서 홈 화면에 추가하면 iOS가 북마크형 스탠드얼론으로 띄우는데, 그때 비밀번호 금고의 origin·표시 모드 판정이 탭 Safari와 갈라질 수 있습니다. 또한 폼이 <dialog> + showModal() 안에 있습니다. 모달 다이얼로그 안의 password 필드가 iOS AutoFill 후보에서 빠지는 사례가 플랫폼 쪽에서 보고된 적이 있어, “폼 마크업은 표준인데도 스탠드얼론만 실패” 증상과 잘 맞습니다.

범위는 #4055(원격 바인드에서 WebUI 세션을 오래 유지하거나 토큰 재입력을 줄이는 기능)과 겹치지만 같지 않습니다. #4055는 서버/세션 수명·비토큰 로그인 쪽 설계이고, 이 이슈는 “이미 있는 비밀번호 관리자 AutoFill이 홈스크린 앱에서만 안 먹는다”는 클라이언트/플랫폼 구멍입니다. 지금 dev의 메인 트랙(#4546 라우팅·probe lease #4626 등)과도 직교합니다. 보안 구멍이라기보다 iPhone으로 LAN/Tailscale 대시보드를 쓰는 운영자의 반복 입력 비용 문제입니다. 재현 OS는 리포터 기준 iOS + 서버 Windows 11, 대시보드 버전은 2.48.0으로 적혀 있으나 해당 다이얼로그 뼈대는 현재 dev에도 그대로 있어 회귀로 사라진 기능은 아닙니다.

gui/src/admin-token-dialog.ts:135-150 - submit에서 preventDefault 후 fetch 검증만 하고, 성공 시 navigator.credentials.store / PasswordCredential 저장 호출이 없음. iOS 스탠드얼론에서는 AJAX 로그인 뒤 저장 제안이 안 뜨는 대표 원인 후보.
gui/src/admin-token-dialog.ts:28-37 / 176-178 - 폼이 네이티브 dialog.showModal() 모달 안에 마운트됨. iOS Password AutoFill이 모달·오버레이 필드를 로그인 폼으로 못 볼 수 있음.
gui/src/admin-token-dialog.ts:51-58 - username이 고정값 OpenCodex + readOnly. 탭에서는 통하더라도, 스탠드얼론·비표준 포트(LAN/Tailscale) origin과 묶일 때 금고 매칭이 약해질 수 있음.
gui/index.html - apple-mobile-web-app / web app manifest(display:standalone) 선언이 없음. 홈스크린 추가 시 탭 Safari와 다른 AutoFill 정책이 적용될 여지가 문서화·대응되어 있지 않음.
gui/src/api.ts:286-289 - 프롬프트 수락 토큰은 메모리 session에만 유지. 브라우저 금고에 안 남으면 홈스크린 앱을 다시 열 때마다 긴 토큰을 다시 붙여 넣어야 함(리포터 고통의 직접 원인).

메인테이너의 판단이 필요한 지점

• iOS 스탠드얼론 AutoFill을 “지원 목표”로 둘지, 문서에 한계로 적고 Safari 탭/비밀번호 앱 복붙을 공식 우회로로 둘지.
• 수정 축을 (a) 다이얼로그를 모달 밖 일반 페이지/비dialog 폼으로 바꾸기, (b) Credential Management API로 명시 store, (c) #4055식 서버 세션 쿠키·수명으로 AutoFill 의존을 줄이기 중 어디에 둘지.
• Tailscale/LAN hostname·비표준 포트 origin에서 비밀번호 금고 항목이 탭과 홈스크린 앱 사이에 공유된다고 보장할 수 있는지(플랫폼 한계면 코드만으로 100% 해결 불가).
• #4055와 한 PR로 묶을지, 이 이슈는 “폼/다이얼로그/Credentials API” 좁은 버그로 분리할지.

너의 추천

이슈는 열고, help wanted + 짧은 needs-investigation 코멘트로 두는 쪽을 추천합니다. 즉시 merge-train에 태울 핵심 버그는 아닙니다(우선순위 48). 다음 실험 순서는 (1) 같은 빌드에서 폼을 <dialog> 밖 일반 overlay/div로 옮겨 AutoFill이 돌아오는지 확인, (2) 수락 직후 navigator.credentials?.store로 PasswordCredential 저장 시도(지원 브라우저만), (3) 그래도 스탠드얼론만 실패하면 index에 PWA 메타/manifest를 최소로 넣고 재현, (4) 플랫폼 한계로 판명되면 가이드에 “홈스크린 앱 AutoFill 미보장 → Safari 탭 또는 #4055 세션 유지”를 명시. types.ts/config.ts 분할과는 무관하고 중복 이슈로 닫을 대상도 아닙니다(#4055는 인접·비중복).

이 댓글은 grok-bot이 작성했습니다

[x3M3x]

Correction on the original report: Safari proper (regular tab) does recognize the password field and does offer save/AutoFill — that part was never broken. The issue is specific to standalone mode (adding the page to the home screen and launching it as a web app): WebKit does not render password AutoFill or save prompts in standalone mode because that UI belongs to the browser chrome, which is absent.

This is a platform limitation, not something the dashboard can fix by changing the form.

A workaround has been implemented in #4649: an opt-in "Remember on this device" checkbox on the sign-in dialog stores the accepted token in localStorage, so the standalone web app signs in silently on subsequent launches. The token is verified server-side before use, and is cleared if rejected or if the checkbox is unchecked.