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

comment

Browse source
This commit is contained in:
Joey Hess 2024-10-17 10:01:31 -04:00
parent 8f96f7b16b
commit 6c65de35f0
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 28 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

28
doc/bugs/p2phttp__58___drop_difference_wideopen_unauth-readonly/comment_5_f4cd5bba64cc01813591ea6fc2f0c55c._comment Normal file
View file

@ -0,0 +1,28 @@
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
date="2024-10-17T13:36:56Z"
content="""
> I see. Is a combination of `--unauth-*` and `--authenv` supposed to work?
I didn't consider combining the two in the current implementation, so
behavior is essentially undefined. It happens to check for `--unauth-*`
before `--authenv` currently.
> I think wanting anonymous read and authenticated write access is quite common, so maybe this should be supported?
Agreed.
> the issue that a drop on the client-side will try to lock, gets a 401,
> and asks for credentials, instead of falling back to the read-only way of
> dropping
Well there are benefits to it actually locking rather than the fallback. It
allows dropping in more situations. So falling back on a 401 does not seem
like a good idea to me.
It might be that lockcontent should be allowed in a readonly connection.
The only possible issue is that would allow an anon to keep an object locked
indefinitely as some kind of DOS attack, so long as they were willing to
keep a connection open for keeplocked.
"""]]