CBSecurity Blocking Valid JWT

Box Modules cbsecurity
1

I’ve been working with CBSecurity JWT auth for the past couple of days and have found that my token gets invalidated randomly. I don’t think I’m doing anything wrong but I’ve run out of places to look. Here’s my environment.

CF21, Macbook Pro, SQL Server.

My JWT secret is assigned in the config to rule it out as being a problem. Tokens are being stored in the database by the module on authentication. Tokens are set to expire in 24 hours.

The first issue I noticed is that tokens are no longer valid after I reboot my computer even though I’m well inside the tokens expiration. They do remain valid when I restart CF. Seems strange to me.

The second issue I noticed is that every now and then were there is an error my code cbsecurity will block access to a secured function when the token is still valid. I’ve been able to reproduce this by adding and removing the secure flag on a handler (in the component declaration). I think the token is validating correctly because I can see hibernate querying for user in the logs (post jwt validation I think) but the request is blocked by cbsecurity. Restarting CF fixes the issue, and the same token works correctly from their on. cbsecurity logs the following error when the token stops working.

Invalid authentication by User (127.0.0.1), blocked access to event=account.index via annotation (handler) security

It’s a 5 day old app so there isn’t much going on with it yet. CB and all the modules were installed via box last week.

“dependencies”:{
“cbvalidation”:“^4.1.0+30”,
“BCrypt”:“^3.1.0+4”,
“cborm”:“^4.3.2+75”,
“cbsecurity”:“^3.1.0+104”,
“coldbox”:“^6.8.1+5”
},

Any help is greatly appreciated.

2

I ran into this as well, check your .env file. If you have JWT_SECRET in there and its blank, cbsecurity will randomly generate the key thus invalidating the token. if you have this in your coldbox config

"secretKey" : getSystemSetting( "JWT_SECRET","somekeyisetinsettings")

it will see the JWT_SECRET in your .env and use it (which is blank) and then it will auto-create it for you, which seems great, accept on restart, or reinit it changes it.

3

Thanks Scott, I removed the blank value from the .env file and I think that solved my invalid token on reboot issue but I think I also found a bug with how the annotations are being processed or cached.

If I have a valid token that works with a handler secured with the top level “secured” annotation, along with individual function annotations (function index secured=“users:list” () {} ) and remove the secured annotation from the top level of the handler but leave the individual function annotations the token will no longer authorize the request, even though it’s still valid (includes a fwreinit). What’s even stranger is that adding the secured annotation back to the component doesn’t resolve the issue. Only restarting CF will fix this issue. After a restart everything works as expected.

I’m stumped.

4

ideally your code should look like this if you want to set the security at the action (function) level

component{

	function index(event,rc,prc) secured{
	}

	function list(event,rc,prc) secured="list"{

	}
	
}

if it is erroring this way depending on the version you’re using, it may be a bug. I know cbSecurity 3.1 came out recently, I’m on cbSecurity 2 and it’s working as expected.

5

That is exactly how it looks with the only exception being a secured annotation after the component declaration.

component extends="coldbox.system.RestHandler" secured {

  function index(event, rc, prc) secured="users:list" {
   
  }
}
6

I don’t think you can have both. You would need to remove the component declaration. And if that is not the problem, maybe there is an issue with the : in users:list causing an issue. At this point I’m just guessing though

7

According to the docs you can use both.

The firewall will inspect handlers for a secured annotation. This annotation can be added to the entire handler or to an action method, or **both**. The default value of the secured annotation is a Boolean true. This means we need a user to be authenticated to access the action.

I’m going to remove the colon and see if that makes a difference. I appreciate the reply. We’re both guessing at this point!

8

Yes, you can use both. One to secure the component and all functions, and more granular control of each function.

However, I need ACF aggressively cache metadata, so that is the only reason why something like that would happen. I would verify the settings in your CF admin, because ACF is notorious for not picking up annotation changes easily.