Session db save handler discussion

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Session db save handler discussion

Marian Meres-2
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.
Reply | Threaded
Open this post in threaded view
|

Re: Session db save handler discussion

Christian Riesen
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 <[hidden email]> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Session db save handler discussion

Marian Meres-2
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 <[hidden email]> 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.
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Session db save handler discussion

Christian Riesen
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 <[hidden email]> 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 <[hidden email]> 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.
>>>
>>
>