Four embedded views are only a cockpit if they behave like one browser, log into the WordPress admin in the applications tab, and the status tab must already be signed in, close the app tonight, and tomorrow it opens still logged in everywhere. Both behaviours live in one Qt concept, the profile, and this post is the session architecture that made the cockpit feel like a workspace instead of four strangers.
A QWebEngineProfile is a browser identity, cookies, storage, cache, and by default Qt gives you an off-the-record profile that forgets everything on exit, which explains the two failures everyone hits first, tabs that do not share logins because they were given separate profiles, and logins that vanish on restart because the default profile never touches disk. The fix is one shared, persistent profile that every view is created from:
from PyQt5.QtWebEngineWidgets import QWebEngineProfile, QWebEnginePage, QWebEngineView
import os
profile = QWebEngineProfile('visa_manager', parent=app)
storage = os.path.join(os.path.expanduser('~'), '.visa_manager', 'profile')
profile.setPersistentStoragePath(storage)
profile.setCachePath(os.path.join(storage, 'cache'))
profile.setPersistentCookiesPolicy(QWebEngineProfile.ForcePersistentCookies)
def make_view(url):
view = QWebEngineView()
page = QWebEnginePage(profile, view) # every page born from the SAME profile
view.setPage(page)
view.load(QUrl(url))
return view
Read the three settings as the feature list they are. The named profile with a persistent storage path is the workspace’s memory, cookies now live in a real folder under the user’s home directory instead of evaporating. ForcePersistentCookies is the restart behaviour, even cookies the site marks as session-only get written down, which is what keeps the WordPress admin signed in tomorrow morning. And the make_view factory is the sharing behaviour, every view’s page is constructed from the same profile object, so a login cookie set in any tab is instantly every tab’s cookie, one sign-in covers the cockpit, exactly like tabs in one browser, because that is now literally what they are.
The honest caveats that come with the power. Persistent sessions mean the machine holds live logins to the business’s tools, so this design assumes a trusted computer, and the app adds its own login gate in front for exactly that reason, with the password manager post handling credentials properly. Sessions still expire server-side, WordPress and webmail will eventually ask again on their own schedule, persistence removes the daily friction, not the sites’ security policies. And one profile means one identity everywhere, the right choice here, though a design needing two different accounts of the same service would need a second profile by construction.
A few things people ask me about this
Why do my embedded views not share a login? Each view got its own profile, usually by default construction. Build every QWebEnginePage from one shared QWebEngineProfile and cookies become common property.
Why does my login disappear when the app restarts? The profile has no persistent storage path, or session cookies are not being persisted. Set setPersistentStoragePath and ForcePersistentCookies on the shared profile.
Next
With sessions solved, the cockpit takes its real shape, the four actual services, WordPress applications, the status admin, the Tawk.to inbox, and webmail, wired into a navigable window. That assembly is the next post.