Saving session tokens by default? (or: other ways to save login info)

[jeffbowman]

I have stored my credentials in my .authinfo.gpg file, it would be nice to be able to have ement use those credentials. For example, this call will lookup the password:

(auth-source-pick-first-password :host "element.io")

or to be more specific in the event of multiple "element.io" passwords:

(auth-source-pick-first-password :host "element.io" :user "@me:matrix.org")

In theory, the user would type in their username on connect, then if one of the above incantations didn't return a password, prompt the user for their password and maybe offer to store it in their .authinfo.gpg file, if gnupg is installed. (maybe checking with:

(executable-find "gpg")

and then not offering to store the password if that command returns nil).

[alphapapa]

Please see #109. As I mentioned in the chat room, I don't plan to support it directly.

Also relevant is the way Matrix authentication and sessions work: the user only need submit a password once, then a session token is returned, which is what should be stored by the client--not the password. (IOW, it would be a mistake to log in with username and password each time, because that would create a new session token each time, which the user would eventually have to manually delete using the Element web client.) But AFAICT auth-source isn't designed to support this use case. So. e,g. if the user needed to invalidate a session token and make a new one, the user would have to manually edit the text file to fix it--and while that's easy for you and me, it's not something I want to try to explain in an error message to users who expect it to Just Work.

What's needed is a more modern "secrets" API for Emacs. There are some other libraries out there, but none that I know of which are built-in to Emacs, so... If Emacs itself ever gains a better such API, I'll be glad to support it.

[viiru-]

I'm not sure if this is all that excellent but here's how I'm handling this:

(defun viiru/ement-connect (host)
  (if (ement--read-sessions)
      (call-interactively #'ement-connect)
  (let* ((found (auth-source-search :max 1
                                 :host host
                                 :port "8448"
                                 :require '(:user :secret)))
         (entry (nth 0 found))
         (password (funcall (plist-get entry :secret)))
         (user (plist-get entry :user)))
    (ement-connect :user-id user :password password))))

So first we check if a session exists, and then we attempt to connect using that session if it does. Otherwise we fetch the username and password from auth-sources and use those. Feel free to improve, my elisp is rudimentary at best.

[jeffbowman]

Also relevant is the way Matrix authentication and sessions work: the user only need submit a password once, then a session token is returned, which is what should be stored by the client--not the password. (IOW, it would be a mistake to log in with username and password each time, because that would create a new session token each time, which the user would eventually have to manually delete using the Element web client.)

Umm... I login with username and password each time. Had no idea this was true, I never see the token coming back.

From *Messages*:

Loading ement...done
Quit
Ement: Checking server’s login flows...
Ement: Logging in with password...
Ement: Sync request sent, waiting for response...
Ement: Response arrived after 0.85 seconds.  Reading 335.4k JSON response...
Ement: Reading JSON took 0.07 seconds
Ement: Reading events... 
Ement: Sync request sent, waiting for response...
Ement: Sync done.  Use commands ‘ement-list-rooms’ or ‘ement-view-room’ to view a room.

Which is why I asked about auth sources, which I use with GNUs and other tools, so it "seemed" like a "good fit". I'll look into other solutions though. Thanks for the information and feedback!

[viiru-]

@jeffbowman For the session to be saved you need to have session saving enabled (ement-save-sessions set to t, it seems to default to nil currently).

[alphapapa]

Yes, since the session token is stored in plain text, I leave the option to save it off by default. It's not ideal, but it seems like the best compromise at the moment. But I'm open to suggestions about how to improve it.

I'll repurpose this bug for that.