I have an idea of what your problem may be.
In your SecurityManager you have this code:
<cfelseif isDefined(“username”) AND isDefined(“password”) >
Firstly, you are not scoping where you are looking for those variables and they aren’t passed in to the userValidator() method. That leads me to believe that they are probably being scope-hunted for and found in the URL or FORM scope from your login form. Those should probably be rc.username and rc.password. Actually, I prefer not to deal with the request context at all in my services. I would personally get the username and password out of the request collection in the handler and pass them through as separate explicit arguments to your method. Another issue with hitting URL or FORM directly are that you cannot unit tests easily since you have broken encapsulation.
Regardless, that is forgivable-- the bad part is when you set username and password. Those variable aren’t varred (which is why I always type out local.username so it’s obvious) which means you’re setting your username and password into the variables (persistent, private storage in the CFC). Then, down below you get those same values with this code (the pound signs aren’t necessary here):
<cfset results = instance.UserService.authenticateUser(username=#username#,password=#password#,resultObj=#oResult#) />
So, the first person to log in gets their credentials permanently stored in the SecurityManager, and every person after them uses the original, cached credentials to authenticate.
To test this theory, add a this method into the SecurityManager.
Then after logging into your app, call that method from a test page and see if the username and password of the first person to log in are stored in the variables scope of the CFC.
Your dev settings are probably causing singleton objects to be re-created on every request which means the SecurityManager never gets persisted across requests and never gets a chance to reuse the username and password.
ColdBox Platform Evangelist
Ortus Solutions, Corp