No downside. Make sure your session memory limitation doesn't stop you from doing this. I have worked with VERY large sessions in PHP that store a good amount of data there. However,
Firstly: justify why you need to store this much data in the session (are these values constantly used throughout the site?)
Secondly : considering using SERIALIZE() php function to put it altogether into a string format under one session value.
i try to check user authorization on each page... so instead of querying the database on each page load... i just wish to query the whole array of permitted pages upon log on and just check the session variable each time for each page.
So when the user authenticates they have a set of pages loaded into the session that they're "allowed" to utilise. So on each page you're checking the current page name against what's in their session array to see if it's a valid option. Ok that's fine, and sounds like it should work.
However, how are you storing these "page" values/names and what happens when you add another page to your website? For EVERY user that needs it do you have to update their respective database column entries?
What does your database DDL look like?
i'm actually maintaining groups, right now divided into
something like admin/ - for higher levels
encoders - for the users of the full system
and viewers for those external to the dept.
so it's similar to ms access authorization on objects...
however, i'm still considering the addition of a further table that would hold user accounts versus specific pages that the would have specific denial
that would be similar to windows' approach on folder/file security...
an advisor of mine insists there's a downside to maintaining multi vars in the session var... and i've yet to see something on this point...