Setting HOSTNAME=0.0.0.0 made Next.js standalone canonicalize request.url to
http://0.0.0.0:PORT. The connector OAuth callback's NextResponse.redirect built
its Location from that URL, so navigating it flipped window.location.origin from
http://localhost:PORT to http://0.0.0.0:PORT. The backend CORS allowlist matches
localhost/127.0.0.1 only, blocking every subsequent API call until app restart —
producing the "no internet" / app-down state after connecting any connector.
Adds two diagnostic events to surface OAuth-redirect failures we can't
reproduce on Linux:
- desktop_oauth_redirect_intercepted fires from inside onBeforeRequest
with the original host, path, and target port — confirms the rewrite
actually ran.
- desktop_oauth_redirect_missed fires from a read-only onCompleted
listener when a /dashboard/*/connectors/callback URL lands off-localhost,
meaning the rewrite filter didn't catch it. This is the smoking-gun
event for "connector OAuth dies on mac/win" reports.
Read-only; no behavior change.
The interceptor previously matched a strict `${HOSTED_FRONTEND_URL}/*`
prefix and did a naive String.replace, which broke whenever the backend
NEXT_FRONTEND_URL differed at all (apex vs www, http vs https, or a
self-hosted domain). Now:
- Match by host: apex + www. sibling, both http and https.
- Rewrite via URL parsing so only protocol/host change; query strings
containing the host as a value are left intact.
- Read HOSTED_FRONTEND_URL through getHostedFrontendUrl() which honors
a SURFSENSE_HOSTED_FRONTEND_URL_OVERRIDE env var, letting self-hosters
point their builds at their own frontend without rebuilding.
Default behavior is identical when override is unset and backend host
matches the baked-in value.
setupDeepLinks() only listened for second-instance and open-url events.
On Windows/Linux a fresh launch via `surfsense://` delivers the URL in
argv of the first instance, where it was silently dropped. Scan argv on
setup so the existing handlePendingDeepLink() pass picks it up.
- Implemented IPC channels for managing auto-launch settings.
- Enhanced main process to handle auto-launch behavior on startup.
- Updated UI components to allow users to configure launch options.
- Integrated analytics tracking for auto-launch events.
This commit introduces the ability for users to enable or disable the application launching at system startup, along with options for starting minimized to the tray.
- Added event tracking for desktop app activation and quitting.
- Introduced analytics bridge in preload script to handle user identification and event capturing.
- Updated IPC channels to support analytics-related actions.
- Enhanced analytics functionality in the main process to track user interactions and application updates.
- Integrated analytics tracking for folder watching and deep link handling.
- Improved connector setup tracking in the web application.
This commit enhances the overall analytics capabilities of the application, ensuring better user behavior insights and event tracking across both desktop and web environments.
- Added a check in the desktop release workflow to ensure version tags follow semantic versioning (semver) format.
- Enhanced the auto-updater to log a message and skip updates if the app version is not valid semver.
- Improved type definitions for event handlers in the auto-updater for better TypeScript support.
- Updated the quick ask window URL to include a query parameter for quick assist mode.
- Introduced a constant to detect quick assist mode based on the URL parameter in the assistant message component.
- Simplified state management for quick assist detection, improving component performance and clarity.
