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 <[email protected]> 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 <[email protected]> >> 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. >>> >> >
