EAM wants a new authorizationCode each time while using sddm.

[pinksquare]

Describe the bug If i close the app, it wants a new authorizationCode each time . It only happens when sddm is chosen as login manager. If i'll choose gdm - the problem disappears

Steps to reproduce the behavior:

1. Enable sddm
2. Open eam and type in authorizationCode
3. Close eam
4. Open eam

Desktop:

• OS: Fedora 37 KDE and Kububtu 22.10
• EAM Version: 3.8.3

[aknarts]

That is strange, that the login manager would cause this but I presume that gdm launches the SecretService and it all rolls from there. I am not sure why it does not fall back to the non SecretService storage though. Would you happen to have logs from the run where it failed to relogin?

[pinksquare]

- [DEBUG] - /app/share/epic_asset_manager - [DEBUG] - - [DEBUG] - 3.8.3 - [INFO] - Epic Asset Manager (io.github.achetagames.epic_asset_manager) - [INFO] - Version: 3.8.3 () - [INFO] - Datadir: /app/share/epic_asset_manager - [DEBUG] - GtkApplication::startup - [ERROR] - Unable to initialize Secret service no secrets will be stored: zbus error: I/O error: No such file or directory (os error 2) - [ERROR] - Unable to load secrets from Secret service (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:28.489: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:28.489: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:28.489: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:28.489: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:28.489: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:28.489: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:28.490: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:28.490: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:28.493: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:28.493: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): Gtk-CRITICAL **: 02:33:28.528: Unable to register the application: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer: unit failed. (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:36.686: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:36.686: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed (epic_asset_manager:2): GLib-GIO-CRITICAL **: 02:33:36.686: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed

[aknarts]

That is very curious.. Based on those errors it should have fallen back to the unencrypted storage... And those GTK log lines should not be there either. Will take a look.

[geekosaurusR3x]

Hi

Same as here.

Desktop:

OS: Endavour OS (Arch base) 
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.4.3-arch1-1 (64-bit)
EAM Version: 3.8.4 from aur

➜ epic_asset_manager 

(epic_asset_manager:5715): Gtk-WARNING **: 08:54:19.181: Unknown key gtk-modules in /home/geekosaurus/.config/gtk-4.0/settings.ini

(epic_asset_manager:5715): Adwaita-WARNING **: 08:54:19.191: Using GtkSettings:gtk-application-prefer-dark-theme with libadwaita is unsupported. Please use AdwStyleManager:color-scheme instead.

[draskmont]

Similar issue. EAM asks for authentication each time the application opens but, in my case it manages to connect to the secret service. Seems like the secret_service crate returns a locked 'collection' on KDE, even if pam is configured to unlock kwallet when you login.

As a workaround, before opening EAM, running a program with the sole purpose of unlocking the collection gets rid of the problem until you logout.

use secret_service::{blocking::SecretService, EncryptionType};

fn main() {
    let ss = SecretService::connect(EncryptionType::Dh)
        .expect("Cannot connect to secret service");

    let collection = ss.get_default_collection().expect("Cannot get default colelction");
    if collection.is_locked().unwrap() {
        collection.unlock().expect("Error unlocking crate");
        println!("Default collection unlocked");
    }
}