Skip to content

Fix Snapmaker account login not persisting across restarts - #715

Open
amitamit10 wants to merge 1 commit into
Snapmaker:mainfrom
amitamit10:fix/persist-snapmaker-login-session
Open

Fix Snapmaker account login not persisting across restarts#715
amitamit10 wants to merge 1 commit into
Snapmaker:mainfrom
amitamit10:fix/persist-snapmaker-login-session

Conversation

@amitamit10

@amitamit10 amitamit10 commented Aug 13, 2026

Copy link
Copy Markdown

Summary

Fixes #669 (and the same underlying cause behind the related reports in #226, #116, and #716).

The native SMUserInfo struct (m_login_userinfo), which backs sw_GetUserLoginState for the embedded Flutter login webview, was only ever populated in-memory during an active login flow (WebSMUserLoginDialog::OnNavigationRequest) and was never written to or restored from AppConfig. Every app restart therefore started with an empty, logged-out struct — regardless of whether the embedded webview's own localStorage still had a cached token — so the login screen reappeared on every launch even though the account token itself was still valid.

This was reproducible outside the Flatpak sandbox too (confirmed on a from-source Linux build), which rules out sandbox/permission causes such as keyring access or the webview's local-server port.

Platform scope

All existing reports of this symptom are Linux-only, but the affected code (WebSMUserLoginDialog::OnNavigationRequest, GUI_App::sm_get_login_info, the SMUserInfo struct) has no #ifdef _WIN32 / __APPLE__ guards anywhere — it's plain cross-platform C++ shared by every build. The native "am I logged in" check always reads from m_login_userinfo, which resets to its default (logged-out) state on every process launch regardless of OS or webview backend (WebKitGTK/WebView2/WKWebView). I don't have a Windows or macOS machine to confirm directly, but nothing in the code path is platform-specific, so this likely affects those builds too, just underreported so far.

Fix

  • On successful login (WebSMUserLoginDialog.cpp), persist token/account/nickname/icon/id to a new sm_user AppConfig section and save immediately.
  • On startup (GUI_App.cpp), right after AppConfig::load() and before the webview's first sw_GetUserLoginState call, restore the saved session into m_login_userinfo if a token is present.
  • On logout (sm_request_user_logout), clear the persisted sm_user.token so a revoked session isn't restored on next launch.

Test plan

  • Built from source on Linux (Ubuntu 24.04), logged in via Login/Register
  • Confirmed sm_user section written to AppConfig (~/.config/Snapmaker_Orca/Snapmaker_Orca.conf) with token/account/nickname/icon/id
  • Fully quit the app, relaunched — session restored, sidebar shows the logged-in account instead of Login/Register
  • Repeated across multiple restarts, consistent
  • Not yet verified on Windows/macOS — the fix touches shared, platform-agnostic code, so it should apply, but a maintainer/tester with those platforms should confirm

The native SMUserInfo struct (m_login_userinfo) that backs
sw_GetUserLoginState was only ever populated in-memory during an
active login flow (WebSMUserLoginDialog::OnNavigationRequest) and
was never written to or restored from AppConfig. Every app restart
therefore started with an empty, logged-out struct regardless of
whether the embedded webview still had a valid cached token, so the
Snapmaker login screen reappeared on every launch.

This persists the token/account/nickname/icon/id to a new "sm_user"
AppConfig section on successful login, restores it into
m_login_userinfo right after AppConfig::load() during startup
(before the webview's first sw_GetUserLoginState call), and clears
the persisted section on logout so a revoked token isn't restored.

Fixes Snapmaker#669
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Login session lost on every restart (Flatpak) — embedded webview uses random local port, breaking localStorage persistence

1 participant