On Mon, Dec 08, 2025 at 01:34:55AM +0100, Omar Polo wrote:
> Stefan Sperling <stsp@stsp.name> wrote:
> > On Mon, Dec 01, 2025 at 11:17:39PM +0100, Omar Polo wrote:
> > > [...]
> > > I think we should 'fix' this and at least enable auth for the website.
> > > I think it doesn't make much sense to protect the history but not the
> > > resulting tree at the tip :p
> > 
> > I am not sure what value authentication would add to this feature.
> > 
> > The reason we need authentication is either to protect a private repository
> > or to block web crawlers from hitting expensive pages like diff and blame
> > over and over, wasting resources.
> 
> I got the idea for the use-case by reading your EXAMPLES section.  if we
> have, say, the doc exposed as /doc/api/1.x/ and the repo itself is
> private (not talking about crawler protection) then why not having the
> doc private as well?  I'm seeing this mostly as an utility service,
> where you can also browse some doc privately.
> 
> but this can be mostly noise at this point, I don't have a real use-case
> for it and if you don't think it's useful, let's wait for feature
> requests :)

Thinking about this some more, I think you are right that we should
allow authentication for websites to be configured by the user.

The website and authentication features are orthogonal, i.e. there are
no bad side effects from flipping them on/off independently.

When authentication settings are inherited from global or server scope,
not having them apply inside a website block might be surprising. When
authentication is enabled globally, we will probably be going to meet
user expectations better when they have to type 'disable authentication'
explicitly before a website is exposed.

And there will probably be use cases for having authentication enabled
for websites. E.g. blocking crawlers temporarily, reviewing websites
that are still in draft stage among a private group of people, and
restricting access to private information related to a project where
this information is displayed on a website for convenience.

There would be little maintenance effort for us to support this.
We could make website blocks embed 'enable authentication' and 'disable
authentication' statements much like repository config blocks do, using
the same inheritance semantics.