Currently, visiting the project page of an unlisted project will only
show public resources associated with that project (when not logged in
as the owner of the project). This commit shows unlisted resources as
well.

This commit also allows contributors who are given access to a private
project to see all the resources associated with it regardless of their
visibility.

The behavior for public projects remains unchanged (i.e., only public
resources are shown).
---
A few questions:
- Is a hybrid_method the best way to achieve this?
[message trimmed]

On Thu Sep 2, 2021 at 2:08 PM EDT, Rob Prentiss wrote:
> Currently, 'getRootURL' is configured to only return 'https' for the
> proto when the request is using TLS. This is not actually achievable
> when using a reverse proxy for TLS termination, so the root URL never
> has 'https' for the proto.0

Minor typo: extra zero after proto.

> This commit adds a checks for a protocol hint in the "X-Forwarded-Proto"
> proxy header. If that header is found, the value will be used for the
> protocol.
> ---
>  internal/server/http.go | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)

Thanks!

To git@git.sr.ht:~adnano/kiln
   508e0c2..66f25b0  master -> master

On Thu Sep 2, 2021 at 5:59 AM EDT, oliverpool wrote:
> Every task can now have a [[tasks.feeds]] entry to generate one or more feeds.
> It must have the following arguments:
>
> [[tasks.feeds]]
> input_dir = ""
> title = "Example feed"
> template = "atom.xml"
> output = "atom.xml"
> ---
> I think having [[tasks.feeds]] is fine. Yes it can generate arbitrary files,
> but since they will be provided with the .Pages variable, they will be some
> kind of feed or index.
>

On Thu Sep 2, 2021 at 2:02 PM EDT, Rob Prentiss wrote:
> Would you like me to remove the TLSURIs config entirely? Or leave that
> as an option for a manual workaround?

Yes, it should probably be removed. Anyone using a reverse proxy can
simply set the X-Forwarded-Proto header. Eventually we'll want to
document this behavior when we write documentation for gddo-server.

I don't think we need to support both Forwarded and X-Forwarded-Proto.
Supporting one should be fine.

Personally I would rather use X-Forwarded-Proto as it's simpler. Just
because Forwarded is standardized doesn't mean we have to adopt it.

Looks like we can use the X-Forwarded-Proto header or the newer
Forwarded header. X-Forwarded-Proto is simpler (doesn't require
parsing).

On Thu Sep 2, 2021 at 6:26 AM EDT, Drew DeVault wrote:
> Ah, so it is. Maybe instead of making it configurable we should just
> examine the request state and choose the appropriate protocol on the
> server? i.e. return links which use the same protocol the request was
> made with.

This is actually what we currently do. However, I'm not sure how to
detect an HTTPS request when gddo-server is sitting behind a reverse
proxy. Currently we use https:// links when Request.TLS is not nil.

On Thu Sep 2, 2021 at 2:06 AM EDT, Drew DeVault wrote:
> As far as I'm aware, every browser will fill in the appropriate protocol
> if the user copies a // link from a web page. So I'm still NACK on this
> more complicated approach.

Note that the links on the tools page are in plain text (Markdown and
HTML), so the browser won't fill in the scheme. I'm not sure if we can
use a link to achieve this without removing the code snippets entirely.

On Wed Sep 1, 2021 at 4:03 AM EDT, Olivier C wrote:
> Thanks for the review.
>
> Let me know how I should handle the following points, so that I can make a patch v2:
> - feed => integrate inside feeds?
> - feeds.Permalink or Dir.path?
> (see the details below)
>
> > > +	extraFiles map[string][]byte // extra generated files
> > 
> > Perhaps this field should be named 'feeds' to make it clear what purpose
> > it serves. Eventually we'll also want to remove the current 'feed'
> > field. I don't think we'll be needing to store any other extra files any
> > time soon.