Permissions Caching

[Nick]

I'm currently redesigning the code used for logging in and I need some community input.  Which is the more expected and useful path:

1) Log a user in and cache all their information such as permissions, group assignment, etc.  This would mean group and permission changes would not take effect until next login.  The plus side to this is that performance will increase because there is no longer a need to hit the database each request.

2) Do not cache data and suffer the (minor) database hit.  This means as soon as an admin changes something, it is reflected in the logged-in user.

The 2.0 rewrite is as much for the users of the app as it is for myself and other developers, so please let me know what you need out of it.

[greg.d]

I would say the second option is more preferable.

Greg

[d3matt]

How hard would it be to make this a configurable option?

[cdeniro]

I assume that most users check the 'keep me logged in' so they never really log out so I think the 2nd option is best but if it can be configurable that would be great.

[Nick]

Great input, keep it coming!

[dpulverizer]

1) Log a user in and cache all their information such as permissions, group assignment, etc.  This would mean group and permission changes would not take effect until next login.  The plus side to this is that performance will increase because there is no longer a need to hit the database each request.

Are you saying that each and every request, i.e., any option from the quick links, and operation such as adding a reservation and/or changing a reservation, etc., requires permissions checks?  If that is the case, I would definitely prefer option #1.   I can't imagine too many people needing instant permission changes while a user is logged in.  As long as the permissions would update when a user logs in again, #1 makes more sense to me.

Thanks again for a great program.  I'm running 1.2.5 and just about to implement it company wide for conference room scheduling.

[Nick]

Hitting pages that don't need to check permissions would be excluded.  The heavy hitter pages here would be

Bookings
Creating/editing a reservation
Calendar pages

[dpulverizer]

Nick, thanks for the clarification.   I'm still a strong vote for caching the user's permissions.   I think in almost all installations, you would lose nothing by caching and only gain in the performance increase, no matter how miner.

[pman]

I'm for option #1.  User permissions don't change that often.  If users can be logged in constantly, it would be a minor (but helpful) inconvenience to bump them offline if their permissions change while they are online.  When they log back in, their permissions would be changed.

It could cause confusion if a user is logged in and their permissions change without them knowing about it.  If schedules that were accessible suddenly become inaccessible without warning, it would appear to the user that something "broke".  Also, what would happen if they were accessing a schedule at the time when their access to that schedule is changed?

At any rate, when a user logs on after their permissions have changed, there should be some kind of notification.

phpScheduleIt is a Great program!

Paul

[temadave]

I would be in favor of caching security settings, as far as resource permissions go, but when it comes to administrator/group permissions, those need to be immediate.

[isKlabbe]

I would suggest to cache but have a time out parameter in the cache to see if there should be an update from the database or not.

[Nick]

That's a good idea.  It would be fairly simple to implement at expiration time for the cache.