Description
On a self-hosted Plane instance, mobile app authentication / email deep links attempt to open the /m/auth URL path, which returns HTTP 404 Not Found.
Current Behavior
Clicking a mobile deep link (from the app or an authentication email) that targets /m/auth results in a 404 response from the self-hosted instance. Reviewing the web frontend routing source and the transactional email templates in this repository shows no route registered for that path — it appears to be an endpoint the official (closed-source) mobile app clients expect, but which self-hosted deployments never implement.
Expected Behavior
Self-hosted instances should either:
- Implement a
/m/auth route that completes the mobile deep-link handoff (matching whatever the official app clients expect), or
- Document the intended self-hosted mobile-auth flow so operators can implement an equivalent redirect themselves.
Workaround (if any)
None found in the open-source codebase. A reverse-proxy redirect from /m/auth to the standard web sign-in page avoids the 404 but does not complete a native app deep-link handoff (any auth token parameters in the original URL are lost).
Environment
- Deployment: self-hosted (Docker/Kubernetes), current release
- Relevant config: standard self-hosted install, no custom auth provider
Description
On a self-hosted Plane instance, mobile app authentication / email deep links attempt to open the
/m/authURL path, which returns HTTP 404 Not Found.Current Behavior
Clicking a mobile deep link (from the app or an authentication email) that targets
/m/authresults in a 404 response from the self-hosted instance. Reviewing the web frontend routing source and the transactional email templates in this repository shows no route registered for that path — it appears to be an endpoint the official (closed-source) mobile app clients expect, but which self-hosted deployments never implement.Expected Behavior
Self-hosted instances should either:
/m/authroute that completes the mobile deep-link handoff (matching whatever the official app clients expect), orWorkaround (if any)
None found in the open-source codebase. A reverse-proxy redirect from
/m/authto the standard web sign-in page avoids the 404 but does not complete a native app deep-link handoff (any auth token parameters in the original URL are lost).Environment