Remember Account feature doesn't work

[NaniNoni]

I'm sorry if I misunderstood, but I don't understand the Remember Account feature when I open gtkcord4. I assume it's supposed to save my password, since it's annoying to have to input the password every time. If that's it's supposed to do, it doesn't seem to be working. I can login using my email and password, while leaving the TOTP field blank and ignoring the Enter New Password popup window and I can access discord fine. However, it it asks me for the credentials upon login every time. Could you please explain why this is happening Is password saving just not implemented yet?

[diamondburned]

Check the Logs. You should be able to find them in the three-dot menu. If it's not working, then it's likely because your system doesn't have the right keyring API setup over DBus.

[NaniNoni]

This was in the logs:

2023/06/08 12:29:30 note: account not found from driver: The name org.freedesktop.secrets was not provided by any .service files

Any ideas on what might have caused this? I have no idea what it means. EDIT: I have archlinux-keyring installed and up-to-date if that helps.

[tgm-git]

I have the same problem. Restarting the application logs me out. I have the following message in my log.

note: account not found from driver: org.freedesktop.DBus.Error.ServiceUnkown

I am running purismOS and have gnome-keyring installed

[tgm-git]

I have go-keyring uses the org.freedesktop.secrets and I have checked whether the service is running and it is.

The error shown when trying to use the remember user:

cannot store account as secret
  -failed to get chipher
    -failed to make/get salt
      -incorrect password

I set the encryption password as empty, but I just realised my keychain may have a password.

[tgm-git]

I get the same error when using a password.

After debugging a bit and looking through the code, it looks like no 'account' entry exists in the default keyring and no salt file is generated when using the remember me button. The error message is the same regardless of whether the optional password is supplied. Which is odd, since a salt file shouldn't (as far as I understand) be generated when a password is supplied.

passPrompt.ConnectResponse(func(id int) {
        defer passPrompt.Close()

        password := passEntry.Text()

        switch id {
        case int(gtk.ResponseCancel):
            done(false, nil)

        case int(gtk.ResponseAccept):
            if password != "" {
                done(true, secret.EncryptedFileDriver(ctx, password))
            } else {
                done(true, secret.SaltedFileDriver(ctx))
            }
        }
    })

It is also not clear which password is incorrect from the error message, but the default session is unlocked in my case.

I found some other logs related to this issue. error: cannot store account as secret: failed to get cipher: failed to make/get salt: incorrect password I haven't found where this error originates from yet, but the previously mentioned note about account not found from driver originates in login.go:83.

[tgm-git]

The cannot store account as secret message originates in login/component.go:200.

I can't tell why exactly an 'incorrect' password is error is encountered here, since the default session is unlocked at this point.

[tgm-git]

I spent some time messing about inside the flatpak container and discovered that the secret service was not accessible from within the container.

I discovered this by connecting to the running environment:

flatpak run --command=bash xyz.diamondb.gtkcord4

And then pinging the secret service:

dbus-send --session --dest=org.freedesktop.secrets --type=method_call --print-reply /org/freedesktop/secrets org.freedesktop.DBus.Peer.Ping

It returned an error:

Error org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown

So I installed flatseal and added org.freedesktop.secrets under Session Bus > Talks. After a restart it is working as expected.

(disregard my bad theme)

[tgm-git]

As far as I can tell, this issue could be resolved by added the following permissions to the flatpak manifest:

permissions:
  - dbus-session: org.freedesktop.Notifications
    allow:
      - send
      - receive
  - dbus-session: org.freedesktop.secrets
    allow:
      - send
      - receive

[diamondburned]

I didn't even think that these issues could've been caused by Flatpak! I completely forgot that this is also packaged on Flatpak, even.

cc @milkknife

[ghost]

Immediately from the third post containing the log with org.freedesktop.secrets I recognized it as a missing permission in flatpak. I will add it right away, sorry for not noticing earlier. In the future if there's anything in the logs mentioning 'dbus' or 'org.freedesktop', and the person reporting the issue is using flatpak, tag me right away.

[ghost]

Fixed by https://github.com/flathub/xyz.diamondb.gtkcord4/pull/9