hgweb: do not ignore [auth] if url has a username (issue2822) The [auth] section was ignored when handling URLs like: http://user@example.com/foo Instead, we look in [auth] for an entry matching the URL and supplied user name. Entries without username can match URL with a username. Prefix length ties are resolved in favor of entries matching the username. With: foo.prefix = http://example.org foo.username = user foo.password = password bar.prefix = http://example.org/bar and the input URL: http://user@example.org/bar the 'bar' entry will be selected because of prefix length, therefore prompting for a password. This behaviour ensure that entries selection is consistent when looking for credentials or for certificates, and that certificates can be picked even if their entries do no define usernames while the URL does. Additionally, entries without a username matched against a username are returned as if they did have requested username set to avoid prompting again for a username if the password is not set. v2: reparse the URL in readauthforuri() to handle HTTP and HTTPS similarly. v3: allow unset usernames to match URL usernames to pick certificates. Resolve prefix length ties in favor of entries with usernames.

     1

Test the GPG extension

     2

     3

  $ "$TESTDIR/hghave" gpg || exit 80

     4

  $ cat <<EOF >> $HGRCPATH

     5

  > [extensions]

     6

  > gpg=

     7

  > 

     8

  > [gpg]

     9

  > cmd=gpg --no-permission-warning --no-secmem-warning --homedir $TESTDIR/gpg

    10

  > EOF

    11

  $ hg init r

    12

  $ cd r

    13

  $ echo foo > foo

    14

  $ hg ci -Amfoo

    15

  adding foo

    16

    17

  $ hg sigs

    18

    19

  $ hg sign 0

    20

  Signing 0:e63c23eaa88a

    21

    22

  $ hg sigs

    23

  hgtest                             0:e63c23eaa88ae77967edcf4ea194d31167c478b0

    24

    25

  $ hg sigcheck 0

    26

  e63c23eaa88a is signed by:

    27

   hgtest