Hi Tarique
This would mean no need to query Acos for findAll queries, other than at
login (at which time you select all of their Acos and store them in a
session or cache).
We will very quickly run out of memory if session is kept in memory,
if not reading large number of ACOs from cache/file based session
would be *almost* just as expensive as queries from a database.
This implies heavily that limiting the number of Acos is the key. Can
you give an example of how a user may accumulate large numbers of Acos?
(Other than a "superuser" who would logically have access to everything
I ask this not to be argumentative, only to try to get a better
understanding of the issue. I may well be facing the same problems as
you, only I haven't realised it yet! :-)
After that it is just a matter of limiting the
number of Acos included in an IN () clause to a reasonable number,
possibly based on model type, or some other criteria.
As soon as we introduce 'some other criteria' the solution becomes app
specific. I am getting more and more inclined to believe that access
restriction to data will always have to be based on app specific
criteria.
I think that you are probably right. The question then becomes: is this
a problem? If so, why is it a problem?
Are you intending for your Cake app to share its security data with
other applications? If your application essentially stands alone, then
surely it won't matter if its Acos are application specific?
Regards,
Langdon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
