[dev] Horde_Share_Base::listShares()

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>>>
>>>> Quoting Jan Schneider <jan at horde.org>:
>>>>
>>>>>> ...and to contradict myself again, I actually think it would be  
>>>>>> possible to keep using the gallery ids. I'll try to work this  
>>>>>> out on a separate branch and see where it goes.
>>>>>
>>>>> I buy the argument for shorter URLs, but non-guessable URLs for  
>>>>> direct guest access have their merits too.
>>>>
>>>> Long non-guessable URLs should definitely be present, but should  
>>>> use a separate value than the primary key, one that can be  
>>>> changed/regenerated/revoked separately from the whole share. Also  
>>>> they should be at least 32 characters, maybe 40, to be a good hash.
>>>>
>>>> To make sure I'm clear, I'm hugely in favor of supporting such a  
>>>> system, especially for things like calendar sharing.
>>>
>>> Like I said, this is already possible with revoking SHOW  
>>> permissions from a share. I'm not sure we want yet another key to  
>>> access shares though, beside the id and the share name. That one  
>>> is only 23 chars long though.
>>
>> The advantage of a separate key is that you can send it to someone,  
>> but if you worry that it's been compromised, you can just change  
>> it. Also just having it not tied to the primary key means that  
>> we're insulated from backend changes.
>
> So in full consequence this means removing the share names, using  
> share ids internally, and adding a new attribute with a unique,  
> interchangeable id.
>
> Of course, if we drop share names, we break other URLs too, e.g.  
> calendar subscriptions.

The guest access piece seems like a red herring here - I have strong  
opinions about how we implement that, but whether or not (or how) we  
do that is irrelevant for the other decisions here.

-chuck