Push requires manual password entry even when auth data is stored

Issue #13 duplicate
Levi Bard
created an issue

It appears that mercurial_keyring is falsely detecting an authorization failure, then invalidating stored auth data. Using Mercurial 2.0, the issue appears to manifest identically on Linux (Ubuntu 11.10), Windows (7 x86-64), and OSX (10.7).

{{{ $ hg --debug push pushing to http://rhodecode/mybranch using http://rhodecode/mybranch sending capabilities command [HgKeyring] Keyring URL: http://rhodecode [HgKeyring] Username found in .hg/hgrc: levi [HgKeyring] Looking for password for user levi and url http://rhodecode [HgKeyring] Keyring password found. Url: http://rhodecode/mybranch, user: levi, passwd: * query 1; heads sending batch command [HgKeyring] Keyring URL: http://rhodecode [HgKeyring] Cached auth data found. Url: http://rhodecode/mybranch, user: levi, passwd: * searching for changes all remote heads known locally query 1; heads sending batch command [HgKeyring] Working after bad authentication, cached passwords not used {'realm': 'RhodeCode authentication', 'user': 'levi', 'authuri': 'http://rhodecode/mybranch?cmd=batch'} [HgKeyring] Keyring URL: http://rhodecode [HgKeyring] Username found in .hg/hgrc: levi http authorization required realm: RhodeCode authentication user: levi (fixed in .hg/hgrc) password: }}}

Comments (10)

  1. Levi Bard reporter

    Possibly - I looked at that issue before posting, but I couldn't ascertain whether it was the same root cause. For what it's worth, the repo indicated here does not contain subrepos.

  2. Anonymous

    i am experiencing the same issue... this week i did a fresh new install of osx lion, fresh new install of mercurial, fresh new install of keyring extension... all latest versions... and i have to supply password for push every time... other operations use keychain data

  3. Anonymous

    some further info... the keychain item is stored as an "application password" rather than an "internet password"... i would think that "internet password" is a better choice

    because of this, the "account" field is set to "myaccount@https://somedomain.com"... if it were stored as an "internet password", the account and domain could be stored as separate fields... which i believe is more desirable

    and more importantly... i have two keychain items... one of them has two @ (at symbols) i.e. myaccount@@https://somedomain.com

    i deleted both keychain items, and after pulling and pushing, they both were created again

    is it possible that a naming irregularity is the cause of this issue #13 ?

  4. Ken Watford

    I just experienced this issue. The repository involved does have subrepositories on the same server.

    Prior to this happening, our workstations had Mercurial 2.0, while the server was on 1.9. That worked fine.

    The problem appears to be in the calculation of after_bad_auth at line 120ish. On the basis that I knew that my stored password was correct, on a hunch I forced the value of this to be False. Things went through just fine with that in place. The value seems to be calculated by checking for two identical queries in a row.

    I set find_auth to immediately print out the AuthURI every time it's run. This is what push looks like on a successful run at my workplace:

    pushing to https://example.net/foo
    AuthURI: https://example.net/foo?cmd=capabilities
    AuthURI: https://example.net/foo?cmd=batch
    searching for changes
    AuthURI: https://example.net/foo?cmd=batch
    searching for changes
    no changes found
    AuthURI: https://example.net/foo?cmd=listkeys

    I tried it with an actual authentication error as well, and it's the "capabilities" command that gets repeated. My guess is that repeated "batch" commands should be ignored, but repeated "capabilities" might be a problem. I haven't looked into the protocol though, so I'm just guessing. I'll try it out for a while and see what happens.

  5. Levi Bard reporter

    I've been running successfully with after_bad_auth forced to False since I filed. It's running fine here, but of course my authentication details are correct. ;-)

  6. Log in to comment