Well, the comments also mention that you can explicitly call
sfActions::validate() before dynamically setting
credentials. I think Askeet uses a similar technique to
what's in snippet 18.
-----Original Message-----
From: Joe Simms [mailto:joe.simms websites4.com]
Sent: Thu 10/5/2006 12:18 PM
To: devsymfony-project.com
Subject: Re: [dev] RFC: credentials
Hi Olivier
How do you manage so called dynamic credentials, such as
owner,
group, organisation etc, which can only be determined upon a
request?
I am trying to work out a way of integrating this into the
core, but
obviously the logic for each model could and app change and
therefore
it would have to deal with this flexibility. The aim is to
have the
ability to add a credential only for that request (these so
called
dynamic credentials get erased at the beginning of every
request, or
after execution).
I hope you understand what i mean. There is a snippet
example for an
owner credential, but as it mentions it is a bit of a hack.
Thanks
Joe
On 5 Oct 2006, at 16:49, Olivier wrote:
> Thanks Joe! I appreciate your non-protectiveness!  I
committed
> the alternative version of hasCredential.
>
> The new testing framework is great. It really allows to
commit
> changes with a more peaceful mind (although this
impression is
> perhaps deceptive  ). With
the tests i feel less likely to have
> opened a huge security breach in symfony.
>
> cheers!
>
> == Olivier
>
> Le 4 oct. 06 à 09:14, Joe Simms a écrit :
>
>> Olivier
>>
>> I'm not protective ;) If its better and faster,
which it seems to
>> be, then please commit it.
>>
>> I believe fabien has added some tests for the new
shorthand syntax
>> as well based upon our examples, so thats great.
>>
>> Thanks
>>
>> Joe
>>
>> On 3 Oct 2006, at 20:43, chtito wrote:
>>
>>> Here is a slightly better implementation. It is
shorter (one
>>> function) and faster (you stop as soon as you
can). It is
>>> symmetric with respect to the two
"modes" OR and AND. It passes
>>> all the tests. (but I wrote it before i knew
Joe would write
>>> it... :-/)
>>>
>>> public function hasCredential($credentials,
$useAnd = true)
>>> {
>>> if (!is_array($credentials))
>>> return (in_array($credentials,
$this->credentials, true));
>>>
>>> // now we assume that $credentials is an
array
>>> $test = false;
>>> foreach($credentials as $credential)
>>> {
>>> $test =
$this->hasCredential($credential, ($useAnd ?
>>> false : true));
>>> if ($useAnd)
>>> $test = ($test ? false : true);
>>> if ($test) // that settles the matter
>>> break;
>>> }
>>> if ($useAnd)
>>> $test = ($test ? false : true);
>>> return $test;
>>> }
>>>
>>> cheers,
>>>
>>> == Olivier
>>>
>>> Le 3 oct. 06 à 10:04, chtito a écrit :
>>>
>>>> Here is an idea. We could agree on the
convention that one
>>>> switches from AND to OR for each depth in
the array. In the
>>>> current implementation one starts with AND
and then switch to
>>>> OR, but why not go further? Your statement
would thus become:
>>>> [[root, admin, editor, [supplier, owner],
[supplier, group],
>>>> accounts]]
>>>>
>>>> Here is another example:
>>>> root OR (supplier AND (owner OR
quasiowner)) OR accounts
>>>> would become:
>>>> [[root, [supplier, [owner, quasiowner]],
accounts]]
>>>>
>>>> That approach has several advantages:
>>>> - it covers all the basic needs (i think)
>>>> - it does not break BC
>>>> - it should be fairly easy to implement.
>>>>
>>>> cheers!
>>>>
>>>> == Olivier
>>>>
>>>> Le 2 oct. 06 à 12:10, Joe Simms a écrit :
>>>>
>>>>> Hey olivier
>>>>>
>>>>> Thanks for useful insight, at least i
know how it is possible
>>>>> and can be implemented, but that is
really gonna take some
>>>>> crunching everytime i need to write a
credential!
>>>>>
>>>>> Maybe, to prevent BC issues, we could
add an additional layer
>>>>> of a credential string:
>>>>>
>>>>>>> root OR admin OR editor OR
(supplier AND owner) OR (supplier
>>>>>>> AND group) OR accounts
>>>>>
>>>>> This then gets converted into the
appropriate array required by
>>>>> the existing system.
>>>>>
>>>>> So in a nutshell, if the credential is
a string it tries to
>>>>> parse this into the array property
required by symfony, but if
>>>>> it is an array it simply uses the
existing system.
>>>>>
>>>>> So, how do we convert a string into
this array structure
>>>>> required by symfony???? I haven't a
clue yet? maybe explode OR,
>>>>> check for brackets in each element,
check for ANDS, if AND,
>>>>> explode ands, and then do some fancy
loop to create arrays.
>>>>> Ummmmmm??
>>>>>
>>>>> Anyone else any other ideas?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Joe
>>>>>
>>>>>
>>>>> On 2 Oct 2006, at 10:01, chtito wrote:
>>>>>
>>>>>> It is mathematically possible to
write any logical expression
>>>>>> with the current implementation,
although it would get
>>>>>> redundant and thus awkward to
write. It is based on the
>>>>>> following logical property: a?(b?c)
= (a?b)?(a?c), so
>>>>>> "a OR (b AND c)" can be
coded as "[[a, b], [a, c]]".
>>>>>>
>>>>>> Your statement could be implemented
using the following
>>>>>> identity, derived from the property
above:
>>>>>> a?b?c?(d?e)?(f?g)?h =
(a?b?c?d?f?h)?
>>>>>> (a?b?c?d?g?h)?(a?b?c?e?f?h)?
>>>>>> (a?b?c?e?g?h)
>>>>>>
>>>>>> So although theoretically all
logical expression can be coded
>>>>>> with the current system i
wholeheartedly agree that it is not
>>>>>> flexible enough, although i'm not
sure what would be the best
>>>>>> solution.
>>>>>>
>>>>>> cheers!
>>>>>>
>>>>>> == Olivier
>>>>>>
>>>>>> Le 2 oct. 06 à 10:43, Joe Simms a
écrit :
>>>>>>
>>>>>>> Hi dev
>>>>>>>
>>>>>>> Having had the need to recently
use the fine grain credential
>>>>>>> control i find it a little
unintuitive and a little
>>>>>>> restrictive, i feel that we
should allow for normal logical
>>>>>>> syntax of AND, OR with brackets
to map real life scenarios,
>>>>>>> such as:
>>>>>>>
>>>>>>> root OR admin OR editor OR
(supplier AND owner) OR (supplier
>>>>>>> AND group) OR accounts
>>>>>>>
>>>>>>> currently, the above i do not
think is possible with existing
>>>>>>> syntax, please can someone help
if it is.
>>>>>>>
>>>>>>> Is this likely to change for
the 1.0 release, even if the
>>>>>>> current rules were reversed and
so [admin, root] was admin OR
>>>>>>> root, and [root, admin,
[suppler, owner]] meant root OR admin
>>>>>>> OR (supplier AND owner) ???
>>>>>>>
>>>>>>> I realise that this will break
BC, but currently the logic
>>>>>>> that handles this i believe is
very restricting.
>>>>>>>
>>>>>>> Please correct me if the above
statement can be implemented
>>>>>>> with the existing syntax.
>>>>>>>
>>>>>>> Many thanks
>>>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>> --
>>>>>>> To unsubscribe, e-mail:
dev-unsubscribesymfony-project.com
>>>>>>> For additional commands,
e-mail: dev-helpsymfony-project.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> To unsubscribe, e-mail:
dev-unsubscribesymfony-project.com
>>>>>> For additional commands, e-mail:
dev-helpsymfony-project.com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe, e-mail:
dev-unsubscribesymfony-project.com
>>>>> For additional commands, e-mail:
dev-helpsymfony-project.com
>>>>>
>>>>
>>>>
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>>>> For additional commands, e-mail:
dev-helpsymfony-project.com
>>>>
>>>
>>> --
>>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>>> For additional commands, e-mail: dev-helpsymfony-project.com
>>>
>>
>>
>> --
>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>> For additional commands, e-mail: dev-helpsymfony-project.com
>>
>
>
> --
> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
> For additional commands, e-mail: dev-helpsymfony-project.com
>
--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com
--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com |