[dev] Horde_Share_Base::listShares()

[Jan Schneider]

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.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/