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…
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:
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 ).
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.
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.
Yesterday someone had an interesting use case for the cbvalidation library. I presented at ITB2020 about cbvalidation, and I’ve contributed some code so I thought it had no secrets anymore. But when trying to solve this case I discovered cbvalidation still had some hidden lines for me. When discussing this validation problem we tried to solve it with UDF validators, but -spoiler alert-finally we agreed it was not powerful enough. So time to build a CustomValidator, which is a lot easier than you might think.
I ‘ve been using cbsecurity V1 for a long time. When we switched from a coldbox application to a VUE frontend and coldbox powered API backend we had to revise our authentication requirements. We didn’t want sessions anymore se we needed something which could be sent with each request to provide our authentication.
In this post I will discuss everything needed for a cfml API which is secured with cbsecurity v2.x. I’ll start with some general JWT info, followed by sample code.
In my previous post I explained cbauth based authentication combined with annotation based security. Annotations are easy to understand, so good as a starting point, but if you need something more flexible you need security rules. So when would you need security rules?
In this post I will guide you through setting up cbSecurity with the flexible cbAuth validator and annotation based security. Before we start let’s look at the basics, as described in Getting Started | Overview at https://coldbox-security.ortusbooks.com.
When you install and configure the cbsecurity module it will wrap itself around the preProcess interception point. This point happens before any event execution in coldbox and thus is the perfect point to inspect incoming requests. The cbsecurity interceptor will try to validate your request against a configured validator. The validator will tell back if you are allowed access, and if not , what kind of validation is broken: authentication or authorization.
Authentication is when a user is not logged in
Authorization is when a user does not have the right permissions to access an event handler or event action
I’v been a long time user of cbsecurity v1.x, a security rule engine for. validation incoming request. I think most people have written code for authenticating users and validation their request in some ways, and probably many of you have written and modified this code over and over again. Cbsecurity v1 has been around for a long time, but some people complained it was hard to understand and/or too complex. in the mean time other security modules such as cbauth and cbguard were released which were a bit more limited but easier to use. In februari Ortus released cbsecurity version 2 and in subsequent months more and more features were added, resulting in a product which covers a lot of your security needs.
In my opinion the usability of cbsecurity has increased a lot, but there are many options to choose from. In a series of blog posts I will try to show you what different possibilities you’ll have to use cbsecurity to your advantage.