ShiftInsert.nl

Coldbox and VueJS untangled

CbSecurity and JWT: when are you authenticated?

Some days ago I was polishing my login procedure for my shiny new JWT cbsecurity. When my users are providing a valid username and password I wanted to update their lastLoginDate property, so I can see from my user list when they used the system for the last time. This doesn’t sound to complicated, so I created this code for my login procedure:

try {
  // authenticate yourself
  var myToken = jwtAuth().attempt( rc.username, rc.password );
  // get the current user and update login date			 
  jwtAuth().getUser().setDateLastLogin(now()).save();
  prc.response
    .setStatusCode( STATUS.CREATED )
    .setData({ 'apiKey' = myToken })
}
catch (InvalidCredentials e) {
  prc.response
    .setStatusCode( STATUS.NOT_AUTHENTICATED )
    .setStatusText( "Invalid username or password" )
    .addMessage( "Invalid username or password" );
}

So what’s happening here? I try to get a token by using the jwtAuth().attempt() method. The method succeeds, so I get a token which I have to return to my user. Because of this success I want to update my user’s lastLogin date. Jwt has some handy method to retrieve the current user, so I called
jwtAuth().getUser(), update the DateLastLogin property and save the user. Unfortunately this fails: “General application error: Token not found in authorization header or the custom header or the request collection”. So although I just received a valid token, the system doesn’t know about the current user yet.

Is this a bug? It depends how you look at it. cbSecurity with jwt will assume you can be validated if

  • you provide a valid bearer authentication header, ie :
Authorization : Bearer hereComes.your.Jwt
  • or you provide a valid other header as defined in cbsecurity.customAuthHeader setting. The default is: x-auth-token
  • or you provide the token in the requestcollection. It has the same cbsecurity.customAuthHeader name, so if you have a rc[“x-auth-token”] variable (in the default setting) with a valid jwt token you will be fine.

According to this three conditions, I am still not logged in. I have received a token in my code (on line 3) which I returned in the response. That’s all. Most of the time it’s ok, but if you want to act immediately on the user object (or some other jwt related method which assumes the token is there) there’s an easy trick. Just put it in the rc directly after your login attempt like this:

var myToken = jwtAuth().attempt( rc.username, rc.password );
// x-auth-token OR the value as defined in cbsecurity.customAuthHeader
rc["x-auth-token"]= mytoken;
// get the current user and update login date			 
jwtAuth().getUser().setDateLastLogin(now()).save();

So that was easy! Happy now? Not really. I’ll explain why. It is trivial to add this line to the cbsecurity source, so it will immediately behave as if we just logged in, instead of waiting to a next request. I’ll create a pull request for that, and it is up to others to decide if it is a valid choice. Now I know this I don’t care. I can add this extra line.

But there’s something else which didn’t make me happy, and I found out when trying to debug my issue. When the jwtAuth().getUser() method was throwing exceptions I tried to make it conditional by using the jwtAuth().isLoggedIn() method. To my surprise it returned true, even when jwtAuth().getUser() was not able to return the user. That’s at least confusing. The jwtAuth().isLoggedIn() method is shows quite erratic behaviour. So I created the following code and executed it with several different conditions:

var resultA = jwtService.isLoggedIn(); 
var decodedToken = jwtService.parseToken();
var resultB = jwtService.isLoggedIn();

I logged in to the system, obtained a token and followed this login request with a second request with the above code in the following scenarios.

scenariojwtTokencbauth
session
Storage
cbsecurityresultAresultB
1nonerequestsecurelistfalseexception
2nonesessionsecurelisttrue or false1exception
3yesrequest or sessionsecurelisttruetrue
5yesrequestwhitelistedfalsetrue
6yessessionwhitelistedtrue or false1true
1 depending on session timeout

As you can see, the results of my isLoggedIn() function is quite different each time

  1. No token provided, so we are not logged in (see resultA column). If we try to parse the non-existing token we get. an exception, so this behaviour is normal
  2. In this case, we are logged in although we don’t have a token. This is incorrect, and this just happens because cbauth is storing a userId in a session. But all other token info is not there, so our second step fails.
  3. If we provide a token and our event is secured by cbsecurity, login information is correct
  4. if we provide a token, store cbauth userId in a requestStorage our first call to IsloggedIn is false. Only after parsing our token we are logged in in ResultB.
  5. this scenario is quite simular to 4. Only in this case IsLoggedIn is true most of the time, because it is depending on session storage.

I spent quite some time searching for an explanation for this results. IsLoggedIn is just a shortcut to the cbauth isLoggedIn function. I think this has to be changed. JWT is used in APIs most of the time where session storage is not very desirable. So isLoggedIn should check for a valid token and login to cbauth based on this token, and only return true if both conditions are true.
Other results can be explained by the fact that jwtAuth().parseToken() is not only parsing the token, but also calling the cbauth login, which is a good thing: If you have a valid token you should be logged in. If an event is secured cbsecurity will parse the token and you will be OK. If your event is on a whitelist however, there is no token parsing, even though there is a valid token, so isLoggedIn will return false.

So what can we conclude from this? Let me start by saying I still like the jwt handling in cbsecurity a lot. All encoding and decoding is fine, there is multiple mechanisms for token invalidation, there’s automatic logins on the presence of a token, and we don’t need session storage anymore. So a lot of the hard work already has been done. There’s just a few things to remember:

  • put your token in your rc immediately after your jwtAuth.attempt() call if you have more code in the same handler which depends on jwtAuth()
  • Don’t rely on the isLoggedIn function at the moment, unless you are sure jwtAuth().parseToken() has been called. I will create a pull request for this one.
  • When using JWT you should not rely on cfml sessions. Since cbsecurity JWT authentication is calling the cbauth module, make sure you modify the cbauth settings so it will NOT use cfml sessions by changing the cbauth module setting for sessionStorage, e.g:
modulesettings.cbauth.sessionStorage = "RequestStorage@cbstorages"

It may sound counter intuitive, but the only thing this setting does is deciding where your userId will be stored. Naming it userIdStorage instead of sessionStorage would be more appropriate. Since you send your userId in a JWT on every request you don’t have to store it in a cfml session.

CbSecurity: a custom validator for fine-grained permissions

CbSecurity has some fine mechanisms to work with user permissions (the CbAuth validator) or user roles (CFML Security validator). The cbauth validator is really flexible, but sometimes you still need more options. In one of our projects our users can have one or more fixed roles and we assigned several permissions to each role. Our rules looked like this:

{
  secureList  : "auth.Customers\.index",
  permissions : LIST_CUSTOMERS
},
{
  secureList  : "auth.Customers\.show",
  permissions : SHOW_CUSTOMERS
},
{
  secureList  : "auth.Customers\..*",
  permissions : MANAGE_CUSTOMERS
},
// ......
// block all rule
{
  secureList  : ".*",
  permissions : "JUST_A_PLACEHOLDER",
  whitelist   : whiteRules.toList()
}

This is only a very small part of our rules. We had to keep track of all kind of permission names (and we put them in variables to prevent typo’s) and still had to assign these permissions to a fixed set of roles. Quite some administration. We decided we had more wishes, in our case:

  1. each individual endpoint should have its own permission for very fine-grained control.
  2. any number of roles which we can create in an API
  3. assignment of permission to these roles in the API
  4. assignment of roles to users in the API
  5. and since we are using a VueJS frontend, we wanted a list of ALL available endpoints (based on permissions) for a user
Continue reading

List all foreign keys in SQL server

This post is not very cfml specific, but I am using this a lot with cfmigrations, so it might be worthwhile sharing. Recently I was doing some major restructuring of a database, and most of the time I try to script this using cfmigrations or commandbox-migrations. Recently I had to drop some tables and thought this would be easy with cfmigrations. So I fired up commandbox, and executed

migrate create dropOldTables

which creates a cfc named yyyy-mm-dd_dropOldtables.cfc in my resources/database/migrations map. If you didn’t use commandbox-migrations before, you have to install and init first, as described here. The migration command should be trivial, something like:

function up( schema, query ) {
   schema.drop("ipnumbers");
}
Continue reading

qb: Autodetecting your bind variables in SQL

In an ideal world, everyone is using qb or quick, and you really don’t know what a bind variable is. Before you discovered this ideal world, maybe you were using queryExecute and were executing queries like this one.

var q =queryExecute("Select * from users where userId = #url.UserId#");

This kind of code ( don’t do this in production ! ) is wide open for sql injection attacks. This post is not about sql injection, so we assume you were already so smart to use queryparams, so something similar to this.

var q = queryExecute(
  sql="Select * from users where userId = :myId",
  params =  { myId: { value = rc.UserId, cfsqlType = "integer" }
)
Continue reading

ValidateOrFail: filtering your request collection.

A few weeks ago I blogged about the advantages of validation your request scope vs validating your model. Actually, it is even better to validate your request scope, populate your model with the results of your validateOrFail function and now also validate the model , this time including business logic in your validations.

As explained in this previous post, validateOrFail acts as a kind of filter if you validate a struct. Input of this filter is your request collection( a struct) or a user-defined struct. The nice thing here is: validateOrFail will only return your validated fields, and this way you get rid of all kind of unwanted other fields in your request scope which can help secure your input. At least, that’s what the docs indicate

* @return The validated object or the structure fields that where validated

https://coldbox-validation.ortusbooks.com/overview/validating-constraints

I wouldn’t write this post if this was 100% valid, so let’s see what’s going on based on my simple use case.

Continue reading

Cfcompile to the rescue (part 2)

A few days ago I blogged about some annoying lucee or coldbox behaviour. On syntax errors in components often I didn’t get feedback on the offending file or line numbers. This makes it very hard to debug your application if you made changes in several files at once. After my post I was contacted by Zac Spitzer who asked me if I could file a bug. I already did this a few months ago, but they couldn’t reproduce my case. So we talked about this bug and I digged a little deeper to find out what was wrong.

Continue reading

Cfcompile to the rescue

This is a story about sloppiness, dislexia, or maybe my touch typing skill are just lacking when coding. I also hear friends telling me their cat is sleeping on the keyboard. To add to this disaster, Lucee is not very helpful when trying to decipher my typo’s. I wonder if you ever saw a screen like this:

We all see these ugly screens sometimes, but usually they provide some information on an error. But not this time…

Continue reading

cbValidation: creating a better uniqueValidator

How often do you want to be sure values in your newly inserted records are unique? I just counted in my current project: 28 times. That’s a lot of repetitive code if you validate this requirement each time, so it makes sense to use some kind of uniqueness validator in cbvalidation. In older releases of cbvalidation there only was a unique validator for ORM which looks like this:

{ 
    fieldName : { validator: "UniqueValidator@cborm" },
    // or
    fieldName : { "UniqueValidator@cborm" : {}  }
}

So pretty easy, you don’t have to specify tablenames, fieldnames or primary keys. That’s only possible if you are using ORM entities, because they have all database information included in the entity definition. So if you want to use request collection validation you are out of luck( in a previous post I explained why this might be a good idea ).

Continue reading

cbValidation: validating a model or the request collection?

Recently I was coding a fluent API based on this sample code which was presented at ITB 2020 by Gavin Pickin. When I was testing I discovered I could overwrite existing records when trying to insert new ones, which sounds like a huge security vulnerability. But before blaming Gavin for this let me confess I changed the code a little, just enough to create this security hole. So this exercise showed me the following:

  • never ever populate a model automatically from the request collection without realizing what your customers can insert.
  • validating your request collection before populating your model has it advantages.
Continue reading

CbSecurity: iss issues with JWT

No, this is not a typo. This post will tell you how to prevent some headache with JWT iss claims in cbsecurity. It is quite easy to solve, but since I just spent several hours debugging some very nasty JWT authentication problem, I thought it might be worth sharing. Bottom line: if you are using the iss claim in JWT make sure you specify it yourself, so don’t rely on the default (although that might look attractive). Better yet: ALWAYS specify the issuer claim, even if you think you are not using it. Only read the rest of this post if you really want to know why.

Continue reading
« Older posts

© 2020 ShiftInsert.nl

Theme by Anders NorenUp ↑