Portfolio Performance Built-In | Not storing credentials for API?

Hi,

The new API for downloading historical quotes isn’t saving the credentials between sessions.

Are there any plans to update/improve this?

Hm, my tokens are stored in

~/.PortfolioPerformance/workspace/.metadata/.plugins/name.abuchen.portfolio/secure_storage

I am seeing this in the error logs.

Linux Mint 22.1 fully updated

Version: 0.76.1 (May 2025)
Platform: linux, x86_64
Java: 21.0.7+2, Flathub

No secure storage modules found.

org.eclipse.equinox.security.storage.StorageException: No secure storage modules found.
	at org.eclipse.equinox.internal.security.storage.PasswordProviderSelector.findStorageModule(PasswordProviderSelector.java:220)
	at org.eclipse.equinox.internal.security.storage.SecurePreferencesRoot.getModulePassword(SecurePreferencesRoot.java:224)
	at org.eclipse.equinox.internal.security.storage.SecurePreferencesRoot.getPassword(SecurePreferencesRoot.java:217)
	at org.eclipse.equinox.internal.security.storage.SecurePreferences.put(SecurePreferences.java:230)
	at org.eclipse.equinox.internal.security.storage.SecurePreferencesWrapper.put(SecurePreferencesWrapper.java:128)
	at name.abuchen.portfolio.oauth.impl.TokenStorage.save(TokenStorage.java:186)
	at name.abuchen.portfolio.oauth.OAuthClient.handleSignInCallback(OAuthClient.java:187)
	at name.abuchen.portfolio.oauth.OAuthClient.lambda$1(OAuthClient.java:126)
	at name.abuchen.portfolio.oauth.impl.CallbackServer.lambda$0(CallbackServer.java:118)
	at name.abuchen.portfolio.oauth.impl.CallbackServer$SuccessHttpHandler.handleResponse(CallbackServer.java:55)
	at name.abuchen.portfolio.oauth.impl.CallbackServer$SuccessHttpHandler.handle(CallbackServer.java:39)
	at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:98)
	at jdk.httpserver/sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:82)
	at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:101)
	at jdk.httpserver/sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:871)
	at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:98)
	at jdk.httpserver/sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:847)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)

Und das arbeitet zusammen mit den Daten in

~/.local/share/keyrings/login.keyring

Die Sachen mit “ii” vorne müsstest Du auch alle haben?

~$ dpkg -l | egrep -i "gnome.*keyring"
ii  gnome-keyring                          40.0-3ubuntu3                               amd64        GNOME keyring services (daemon and tools)
ii  gnome-keyring-pkcs11:amd64             40.0-3ubuntu3                               amd64        GNOME keyring module for the PKCS#11 module loading library
rc  libgnome-keyring0:amd64                3.12.0-1build1                              amd64        GNOME keyring services library
ii  libpam-gnome-keyring:amd64             40.0-3ubuntu3                               amd64        PAM module to unlock the GNOME keyring upon login

Is this missing from the Flathub version?

No, this has nothing to do with PP, everything is normally included with the OS.
https://www.baeldung.com/linux/unlock-keyring-fix

Maybe there is a problem if you want to use the PP-datafile on more than one computers, and you have sync the datafile and the settingsfile, but not the workspace and not the keyring. I have not thought about that case.

The sessions are on the same computer with the same user? Or has something changed between the sessions?

Good question. Maybe the sandboxing of Flathub prevents something here?

There is also an Eclipse install on Flathub. There are some differences to configuration I use. For example, the "--persist=.eclipse", could mean it is persisted across sessions. Maybe I find time on the weekend to test. But maybe, you can also cross post to the Flathub Github project? There are much more knowledgable contributors there.

In general, the credentials are stored in an encrypted file. But where to store the password to encrypt the file? For this Eclipse, uses local implementations the secure storage modules. For example, on macOs, it uses the system keychain (that’s why the dialog pops up to ask for permission).

1 Like

Maybe it helps.

1 Like