Show whether --password or PAM authentication is happening

[ben]

Currently, when either sort of authentication is required, gobby only knows that gsasl wants "PLAIN" authentication. Right now, it displays "Server password:" in the password dialogue regardless of whether it is a serverwide password or whether the infinoted will check it via pam.

The server-side should let the client know which of those is the case so that the dialog can be more informative.

[phil]

IMHO it's irrelevant how authentication is achieved if it's user/password. I could even authenticate against $RDBMSOfMyChoice, that's an implementation detail of the server. If there's a distinction between user/password and global password-only, it needs to be exported to the GUI, but then it's pretty clear because you need one information more in the first case.

[ben]

Yeah, the problem is probably the distinction between user/password and global-only password, or maybe system password or infinoted-specific password. Right now we just send the username from the preferences along in either case so the user really does not notice. And gets confused.

[ben]

I have finally gotten around to thinking about this for a bit more. Right now the server side only really knows that there is a sasl context from the infinoted, but everything else is obviously abstracted behind the callback. Should we change that to pass along some token like "server-password required" or "user-password required" to pass along to the client? Can we stuff that into the sasl context we pass to new infxmppconnections anyway? I am vaguely uncertain how to proceed.

[armin]

Can we stuff that into the sasl context we pass to new infxmppconnections anyway?

Technically yes, I think so, though it would be an API break. Instead of using an InfXmppConnection? as session hook we could use a custom struct which contains the InfXmppConnection? but also a string to send to the user. I think we can allocate that struct dynamically and free it when we free the sasl context.

I'm a bit worried about localization of that string - maybe we could use integer codes for "common" tokens plus a fallback string?