[fw-general] Session db save handler discussion
Hi, this is not really ZF related, but I hope you don't mind more generic question. I've never used any other session save handler than the native php one. As far as I know it raises concerns only related to a) the disk read/write security and/or b) potential load balancing problems (sync between servers and session save paths). I am OK with those. Application issues such as number of active users are no problem as well. I would guess the native one is also more performant (perhaps not true if there are thousands+ of active sessions). Are you aware of anything else I should take into account? Thanks in advance. m.
Re: [fw-general] Session db save handler discussion
Debugging. With the database, all your sessions for that one application are in one place. You can see if for example you made a mistake and it just accumulates sessions like crazy. Also you can easier get access to the data and then analyze whats happening. Security. Your sessions are yours, not shared with potentially other users on the very same box that might guess your session id. Highly unlikely, but theoretically possible. It's less likely if your database is properly secured. Thats my 2c Greetings, Christian Riesen On Fri, Nov 12, 2010 at 11:44 AM, Marian Meres marian.me...@gmail.com wrote: Hi, this is not really ZF related, but I hope you don't mind more generic question. I've never used any other session save handler than the native php one. As far as I know it raises concerns only related to a) the disk read/write security and/or b) potential load balancing problems (sync between servers and session save paths). I am OK with those. Application issues such as number of active users are no problem as well. I would guess the native one is also more performant (perhaps not true if there are thousands+ of active sessions). Are you aware of anything else I should take into account? Thanks in advance. m.
Re: [fw-general] Session db save handler discussion
Hello Christian, Debugging. With the database, all your sessions for that one application are in one place. You can see if for example you made a mistake and it just accumulates sessions like crazy. Also you can easier get access to the data and then analyze whats happening. As soon as I am setting different session save path per application I guess I'm playing the same game. Or am I not? Security. Your sessions are yours, not shared with potentially other users on the very same box that might guess your session id. Highly unlikely, but theoretically possible. It's less likely if your database is properly secured. I'm not sure I understand. Are you talking about filesystem security (...other users on the same box...)? Thanks, M. Thats my 2c Greetings, Christian Riesen On Fri, Nov 12, 2010 at 11:44 AM, Marian Meres marian.me...@gmail.com wrote: Hi, this is not really ZF related, but I hope you don't mind more generic question. I've never used any other session save handler than the native php one. As far as I know it raises concerns only related to a) the disk read/write security and/or b) potential load balancing problems (sync between servers and session save paths). I am OK with those. Application issues such as number of active users are no problem as well. I would guess the native one is also more performant (perhaps not true if there are thousands+ of active sessions). Are you aware of anything else I should take into account? Thanks in advance. m.
Re: [fw-general] Session db save handler discussion
Correct, you could set your own path and be in the same area, though I must say I prefer to filter through sessions when debugging on the database. Shared hosting more often than not uses the same storage for all users on the same physical server. Setting your own directory, with the correct permissions, can work, still if the webserver is accessing it with some nobody user, then they would be globally readable on the disk again. This still is very theoretical, so it depends on the level of security you are aiming for. I have worked for companies that would have not accepted this as a solution because it's not secure enough for them. Generally, the major point though is so you can use one session across N machines, which comes in handy when your application grows. On Fri, Nov 12, 2010 at 3:32 PM, Marian Meres marian.me...@gmail.com wrote: Hello Christian, Debugging. With the database, all your sessions for that one application are in one place. You can see if for example you made a mistake and it just accumulates sessions like crazy. Also you can easier get access to the data and then analyze whats happening. As soon as I am setting different session save path per application I guess I'm playing the same game. Or am I not? Security. Your sessions are yours, not shared with potentially other users on the very same box that might guess your session id. Highly unlikely, but theoretically possible. It's less likely if your database is properly secured. I'm not sure I understand. Are you talking about filesystem security (...other users on the same box...)? Thanks, M. Thats my 2c Greetings, Christian Riesen On Fri, Nov 12, 2010 at 11:44 AM, Marian Meres marian.me...@gmail.com wrote: Hi, this is not really ZF related, but I hope you don't mind more generic question. I've never used any other session save handler than the native php one. As far as I know it raises concerns only related to a) the disk read/write security and/or b) potential load balancing problems (sync between servers and session save paths). I am OK with those. Application issues such as number of active users are no problem as well. I would guess the native one is also more performant (perhaps not true if there are thousands+ of active sessions). Are you aware of anything else I should take into account? Thanks in advance. m.
Re: [fw-general] Zend_Acl 1.11 broken my code
Hi All,
I've uploaded a patch to Zend_Acl that covers this use case while being
completely backwards compatible.
I'd really like to see everyone test this so we can feel good about
including it ASAP.
Issue:
http://framework.zend.com/issues/browse/ZF-10649
Patch:
http://framework.zend.com/issues/secure/attachment/13431/ZF-10649.patch
-ralph
On 11/11/10 6:50 PM, Terre Porter wrote:
So I've taken a look since this problem affected my code also.
If I understand the problem correctly would it not be better to just adjust the
isAllowed code to support the changes to the setRule?
if (null !== $resource) {
// keep track of originally called resource
$this-_isAllowedResource = $resource;
$resource = $this-get($resource);
if (!$this-_isAllowedResource instanceof
Zend_Acl_Resource_Interface) {
$this-_isAllowedResource = $resource;
}
// if resource is null, and resources exist then add them instead
} elseif ($resource === null count($this-_resources) 0) {
foreach (array_keys($this-_resources) as $k = $v ) {
if (null !== ($result = $this-isAllowed($role, $v,
$privilege))) {
return $result;
};
}
}
The follow now works as expected.
$acl = new Zend_Acl();
$acl-addRole(new Zend_Acl_Role('role'));
$acl-addResource(new Zend_Acl_Resource('res'));
$acl-allow('role','res', 'privilege');
echo $acl-isAllowed('role','res','privilege')? allowed : denied; //
returns allowed
$acl-removeAllow('role',null,'privilege');
echo $acl-isAllowed('role',null,'privilege')? allowed : denied; // returns
denied
And the second code
$acl = new Zend_Acl();
$acl-addRole(new Zend_Acl_Role('role'));
$acl-addResource(new Zend_Acl_Resource('res'));
$acl-allow('role');
echo $acl-isAllowed('administrator') ? allowed : denied; // returns allowed
Would be the same as : (since null resource is all defined resources)
$acl-allow('role', 'res');
echo $acl-isAllowed('administrator') ? allowed : denied; // returns allowed
Hope that helps.
Terre
-Original Message-
From: Ralph Schindler [mailto:ralph.schind...@zend.com]
Sent: Thursday, November 11, 2010 12:50 PM
To: fw-general@lists.zend.com
Subject: Re: [fw-general] Zend_Acl 1.11 broken my code
I've been looking at this over the past day and I am attempting to find a
solution. As you can see it was a fix for a previous issue:
http://framework.zend.com/issues/browse/ZF-9643
Fixing the previous issue did not break any existing unit tests.
I will get to the bottom of it and figure out a solution that works for
everyone.
-ralph
On 11/11/10 12:32 AM, Valentin wrote:
Hi,
I'm impressed, is exactly the problem reported at bug
http://framework.zend.com/issues/browse/ZF-10649
Thanxx
2010/11/10 Emmanuel Boutongot...@gmail.com
Hi,
A bug has been created for that :
http://framework.zend.com/issues/browse/ZF-10649
I suggest you to vote for its fix ;)
Manu
2010/11/10 Valentinvalen...@valclip.com
Hi,
New version 1.11 have only one change in Zend_Acl line 636:
Old line
$resources = array($resources);
change for this
$resources = ($resources == null count($this-_resources) 0) ?
array_keys($this-_resources) : array($resources);
I've been studying (and debug) all day and how it affects the code
and
not
understand what happens. Any ideas?
Thanks
