Kallithea issues archive

The right way to fix this will be to use the keyring extension on the client side, right?

... and really using keyring might depend on some serious cleanup of it and integration with Mercurial core ...

Also ... where should this secondary pw be stored and managed? Wouldn't that be pretty much an alternative LDAP?

It's not exactly an alternative to LDAP, because there may be situations where you want only to have people who are in an LDAP database able to log in / create an account, and then you would want to give those people the ability to set an "extra password". It would seem sensible to have this be just another optional field they can fill out under the "my account" setting page. It would be stored/managed in whatever database non-LDAP passwords / accounts get stored in (i.e. the postgres / sqlite db that Kalithea is configured to use).

Would you still need this feature once ssh key support is added?

I think SSH key support would be a definite improvement, but not everyone will run Kallithea on a server where they can create new accounts, and allow SSH access. But, typically if you are going to use LDAP for authentication, you are in a setting where you have root access to the machine that Kallithea is running on...

At least for Windows users, I think the 'extra password' option is a lot less painful -- creating and setting up an SSH key under Windows requires a somewhat higher level of effort for beginner users.

The ssh implementation does not require you to create ssh system accounts on the Kallithea server. All user connect using the same system account, it then uses the connecting user's ssh key to authenticate the user against Kallithea's db. This is similar to how bitbucket works. Everyone uses the hg account for ssh. eg ssh://hg@bitbucket.org/conservancy/kallithea.

Christian, I understand how it works -- but one ssh account does need to be created, and root access is required for this, as well as setting this user's default shell.

I'm not sure I completely understand your problem. If you want a password just for kallithea why not simple use the internal authentication?

BTW to prevent users from storing their password in plain text I set up our kallithea instance with kerberos authentication (Windows Active Directory single sign on) https://bitbucket.org/domruf/kallithea/commits/branch/repoze.who https://bitbucket.org/domruf/hgssoauthentication

Dominik, when a user is authenticated via LDAP when logging in to the web interface (this is a requirement in my case), the user currently has no choice but to authenticate with their LDAP password. Even if he tries to change the "internal authentication" password you mention (via the "My Account -> Password" page), the new password is not accepted afterwards, and only the LDAP password will continue to work.

The purpose of this issue is to find a way for users who have initially created an account using their LDAP username/password to not be forced to use their LDAP username/password with their git or mercurial client.