Why does the validator query the database table on every page request?

Communities ContentBox CMS
1

securityService.cfc (the validator)

one of the first things the validator does is getAuthorSession by checking to see if an existing loggedInAuthorID is saved in session, if so it then does authorService.findWhere({authorID=sessionStorage.getVar(“loggedInAuthorID”),isActive=true});

I do not use ORM (please ignore my ignorance). From what I understand findWHERE queries the db (through author entity) for the specific user.

If the session variable “loggedInAuthorID” is already set then user has already been authenticated, so why not save the author information (role, permission, etc) in session so that getAuthorSession does not have to query the db every time?

2

Lets answer your first question.

authorService is the object that is everything to do with the author, findWhere is a method that is part of the underlying ORM frameowrk Luis has put together. So you will find the likes of ALL services extending this framework.

To answer your question on findWhere, because the services extend there entity conuterparts that then extend the ORM framework of ContentBox, that means all these ORM methods are chained back to the service. So in this example you could use findWhere on any of the services.

3

And I meant the framework of ColdBox not ContentBox.

4

Hey thanks for explaining the chaining there - Can’t wait for another small project to get my feet wet with ORM.

My concern is that findWhere is doing a sql query on every page request compared to my validator that is only doing one call per session. In my validator I have to make a third party web service call to get user information for authentication. My direction is to keep these calls to a minimum per session, so I save user information in session. In my getUserSession (equivalent to getAuthorSession method) I do not make a call to findWhere - I simply retrieve the info I need from the SessionStorage.

So I’m questioning the design of the contentbox security validator because I’m wondering if it makes the app more secure to do it this way. Again, I’m not a security expert, but I’d like to be.

5

Wait a minute…

SecurityService is for Authenticating the dashboard and maybe some basic stuff for the front end, are you saying you are using that for Admin and Editors to authenticate or are you doing something for your members here?

If you are referring to users in the context of members of the website / readers aka membership like. Then I would maybe think about it a different way.

For example I have in the works an oAuth2.0 module for ContentBox that is currently working against FaceBook, the concept is the same every single request is Authenticated against Facebook. I have it set up to cache the authentication and other things, but this is a simple securtiyService that is designed for FaceBook.

In other words, you are not tied to having to use the securityService of ContentBox and can very easily lock your module down with its own securityService or your could extend ContentBox to provide both for the module.

But let me discuss Facebook authentication with you.

One of the things that an App on Facebook has to check for, is that they have the permission to do things with the user. Because the user can deny access at any time, the requirement here is that we could request the authentication every request or cache it in the session. But if we cache it in the session then there is a 30 minute or whatever the session is set too, before the application will check again. And that is provided the user doesn’t keep the session open.

So the logical thing there was to hit facebook and authenticate each request, this is not a bug deal for something like this because the time it takes facebook to do this is minimal.

But either way, the decision is what works for what you need it to do.

Now lets go back to your observation…

The SecurityService caches the ID of the Author in the session, at that point that is all it knows. So for the SecurityService to then get more information about what rules the user has or what permissions etc., then a call needs to be made, which is what you are observing.

Does that clear it up some, if you are storing more than the ID in the session, I would seriously have a think about changing that behavior.

6

Everything you said makes sense to me. The facebook example was great.
My app is a simple coldbox app without contentbox, but I used parts of the validator in ContentBox for the rule and permission logic so my validator is mostly custom. Anyways, I have a limit with the third party user web service. I wish it was facebook, but its not even close and I don’t have another choice - the third party stores all the user data.
Also, I am storing more than just the user ID in session. I’m storing a complete array of user string data - the heaviest data being the personal information like email and address, the rest is simple boolean data (about 30 indices of data). So after hearing your last statement and knowing how memory space is used per session I will most definitely change it. Here is what I plan on doing, instead of saving the entire array I will limit my array to 4 to 5 indices and then only retrieve specific data when requested without saving it.
How much damage could I be causing my app when i store 30 variables of data in session? average 2000 pageviews per day.

7

What you could do then is cache that maybe in a DB locally and test locally first, based on session, if the session has expired then you could either ping the service again or pull up the cached local copy.

8

BTW as far as memory goes, you can only gauge that with what you know you have against what you expect to hold per user, normally that isnt a bad thing. Only if the site goes viral could you end up in trouble, unless you have the new cloud based services where it is only going to cost you extra money.

Personally I keep everything in the session as minimal as possible, if it has to be referenced then a quick DB call is nothing in the whole scheme of things and you could even cache that with cacheBox and ColdBox so that if it expires it is then pulled up again, I guess there are many options available to caching that info.

9

Man, I use cachebox for many other things but never thought about using for this particular authentication process. wow, thank you a lot.

My original question then gets answered. Performance is key.

10

lol… I thought long and hard about this, but when I started working on the oAuth2.0 for facebook, I modeled it off the php version. Which caches things in the request and session, I added another layer which was the ColdBoxOCM so it can be kept across servers with better ease, and provide that level of scalability as well.

The only problem with this, is the changing of username and password and other information, in my case with facebook I ended up leaving it at the request level for one site. But in your case you need to also weight into how long you cache it for as well, in terms of your limitation with the 3rd party request.

Just something to consider, if you haven’t already.