Multi "http-basic" for one repo link

[ghost]

#I have a few accounts with different "http-basic" credentials

{
  "name": "Some",
  "homepage": "some",
  "repositories": {
    "repo" : {
      "type": "composer",
      "url": "https://domain"
    }
},
  "require-all": true,
  "require-dependencies": true,
  "archive": {
    "skip-dev": false,
    "directory": "dist",
    "format": "tar"
  },
  "config": {
    "http-basic": {
      "domain" : {
        "username": "some username",
        "password": "some password"
      },
      "domain" : {
        "username": "some username",
        "password": "some password"
      }
    }
  }
}

But I install extensions only from second config. Have I chance to download packages by both config credentials ?

[nitsan-technologies]

Any update here? We have also similar issues, and excited to get resolve.

[SvenRtbg]

It's unlikely that a topic from more than five years ago without any response resolved without anyone noticing.

My initial reaction to the original post was: There are two identical keys named "domain" in the JSON, this will never be json_decode to two entries, but only one - the last one, apparantly.

So if you are unable to configure two different basic auth entries for the same domain in the JSON parsed data, then the code does not even need to address the question of how to detect which auth pair is the correct one - because the code only sees one set of credentials, not two.

And obviously from this situation there are multiple ways out:

• Use the same set of credentials all over the entire domain to get access.
• Use different domain names (vhosts) to access the single server, but indicate to Satis which credential set to use.
• Or build some kind of proxy in front of that domain and access it from Satis instead of directly, and configure credential usage there.
• Last alternative: Identify why and how multiple credentials for a single domain would be used, and send a pull request with suggestions on how to configure that (probably there would only be one key "domain", and then maybe an array of credential sets, and hopefully some indication of when to use them).

[alcohol]

I find the example configuration flawed as "domain" is a meaningless value here; "foo.org" for the first and "bar.org" for the second would make more sense. There is no scenario where "foo.org" and "foo.org" (two identical values) would ever work.

[SvenRtbg]

I don't agree it wouldnot ever work - simply consider that one path needs different credentials than another path, speaking of generic webserver configuration of course.

But I agree it sounds like an unnecessary complication, considering that we are likely talking about a private composer repo hidden behind http-basic auth.

My main point here: If core developers cannot imagine this to be a reasonable request based on info given, it is necessary to explain why this would still be a valid usecase and give details (they would anyways be required for any implementation). So please add more info, @nitsan-technologies .

[alcohol]

Pretty sure we only support hostnames, not path: https://getcomposer.org/doc/06-config.md#http-basic

[SvenRtbg]

Agree - sounds like Satis will inherit the abilities of Composer, and this is unresolvable within Satis, and unlikely to be resolved inside Composer.

[nitsan-technologies]

Thanks, Everyone, for your interest in this issue; @SvenRtbg here is more information.

This issue is closely related to a well-discussed and previously concluded topic at: 🔗 https://github.com/composer/composer/issues/8724

⸻

📌 Overview of the Issue

We have a setup involving multiple products distributed via multiple domains, where each domain requires its own authentication.

Here’s what our setup looks like:

auth.json

{
  "http-basic": {
    "domain1.com": {
      "username": "user1",
      "password": "pass1"
    },
    "domain2.com": {
      "username": "user2",
      "password": "pass2"
    }
  }
}

composer.json

{
  "repositories": {
    "domain1": {
      "type": "composer",
      "url": "https://domain1.com",
      "only": [
        "namespace/product1"
      ]
    },
    "domain2": {
      "type": "composer",
      "url": "https://domain2.com",
      "only": [
        "namespace/product2"
      ]
    }
  }
}

⸻

⚠️ The Core Issue

Even though domain2.com is a proxy or alias of domain1.com, both are treated independently in terms of access control (as they should be). However, when using Satis:

• The resulting composer.lock file records the URL as domain1.com for both repositories.
• This causes authentication failures when Composer tries to download product2 from domain2.com, because the lock file still points to domain1.com.

⸻

✅ Desired Outcome

Each package in the lock file should preserve its original domain so that authentication can match what’s defined in auth.json.

We believe this behavior should be either:

• Respected as part of Satis output, or
• Provided with a configurable option to force domain-specific lock entries.

Looking forward to any ideas or potential fixes that can help support this multi-domain use case.

Thanks! 🙏

[stof]

Given that Satis is a static site generator, the JSON metadata files cannot be changed depending on the domain used to access them to generate the absolute URL of archives referenced in the file. I see 2 solutions here:

• generate 2 separate Satis instance for the 2 domains instead of using a proxy or domain alias
• make your proxy rewrite absolute URLs in the JSON files being returned through the proxy to make them use the proxy domain name (this assumes that the proxy being used is able to perform such rewriting).

[nitsan-technologies]

@stof 💯

[nitsan-technologies]

Got feedback from our server guys; Maybe you can help us on your mentioned suggestions.

===

We tried implementing a proxy with the following settings.

SSLProxyEngine On ProxyRequests Off ProxyPreserveHost On

ProxyPass /.well-known ! ProxyPass /cgi-fpm ! ProxyPass / https://domain1.com/ ProxyPassReverse / https://domain2.com/

AddOutputFilterByType SUBSTITUTE text/html application/json Substitute 's|https://domain1.com/|https://domain2.com/|i'

===

If you set up two subdomains in server that point to the same folder, they will normally remain in the browser's address bar even without a proxy entry. The domain would only be rewritten if your software or rewrite rules in mod_rewrite did so. Therefore, the entire problem should actually be solvable at the web application level.

Checking in the web application itself which domain a request came from and generating an appropriately adapted response is a much cleaner solution than subsequently manipulating the response and risking possible data consistency errors.

[stof]

Checking in the web application itself

This implies that there is a web application.

Satis is generating a static site that is served directly by the webserver.

[nitsan-technologies]

Good news!

We’ve finally resolved the Multi-Credential Issue using a combination of a PHP script for proxy, .htaccess bypass techniques, and smart caching for better performance.

Check out the full solution here: 👉 https://t3planet.de/en/blog/composer-multi-credential-satis-domains/