mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comments

Browse source
This commit is contained in:
Joey Hess 2024-10-18 12:04:48 -04:00
parent d5b59ecba9
commit a3d1d3bcb6
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 44 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

36
doc/bugs/p2phttp__58___drop_difference_wideopen_unauth-readonly/comment_7_8c1a79bda3984d321c51f5922075715f._comment Normal file
View file

@ -0,0 +1,36 @@
[[!comment format=mdwn
username="joey"
subject="""comment 7"""
date="2024-10-18T14:56:10Z"
content="""
In a sense the underlying problem here is that git-annex as a client to
p2phttp does not know if the user wants it to be read-only or prompt for a
password as necessary to perform write operations.
Another way that would be a problem is if a p2phttp server supports both
readonly and authenticated operation, but the user does not have an
account, and is using say, `git-annex assist`, which wants to store content
on the server if possible. So it will prompt repeatedly for a login and
password which the user does not have.
In this sense, the server is fine in sending a 401, the problem is that the
client doesn't know when the user doesn't want that to result in a
password prompt. If the client did know it could treat that 401 the same as
a 403.
Looking at drop locking through this lens, if the client wants to avoid
password prompts and the server requires authentication for lockcontent,
it's reasonable for the client to fall back to checkpresent for dropping.
The same as it's reasonable for checkpresent to be used when the remote is
a dumb http git remote.
The url to the p2phttp remote seems like the natural way for the user to
tell git-annex if they want an anonymous or an authenticated connection.
It already works to use `annex+http://joey@example.com/git-annex/`,
which will make it prompt for my password when operations need
authentication.
So it would make sense to support "anonymous@" and special case that
to treat 401 the same as 403.
"""]]

8
doc/bugs/p2phttp__58___drop_difference_wideopen_unauth-readonly/comment_8_f5564bbd7fd27a2488877c0d641441c0._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="joey"
subject="""comment 8"""
date="2024-10-18T15:50:06Z"
content="""
@matrss would there be a way for forgejo-aneksajo to draw this distinction
between anonymous and authenticated urls in its user interface?
"""]]