ShiftInsert.nl

Coldbox and VueJS untangled

Author: Wil (Page 2 of 3)

CbValidation: UDF or Customvalidator?

August 11, 2020 / / 0 Comments

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.

Continue reading

Cbsecurity (4): JSON Web Tokens (JWT)

July 27, 2020 / / 2 Comments

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.

Continue reading

CbSecurity (2): cbAuth validator

April 22, 2020 / / 0 Comments

Introduction

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
Continue reading

CbSecurity (1): overview

April 20, 2020 / / 0 Comments

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.

Continue reading

Input validation with full null support

January 21, 2020 / / 0 Comments

Adobe introduced full null support in ColdFusion 2018. Before 2018 null values returned by databases and external systems were converted to empty strings. This behaviour made it almost impossible to distinguish between empty strings and null values, and also caused issues with serialization and deserialization. You also had to take special precautions to insert or update null values in a database. Interaction with Java, including CFORM based hibernate could also result in returned null values so we always had te be very careful when trying to handle these dreaded nulls.

Lucee already has full null support since many years, but just as with the latest ACF version, you have to enable this in the administrator, just to stay compatible with older versions of ACF.

So, because of all these null handling issues, why not enable full null support? That’s what we imagined when creating our latest REST based application. But before hurrying to your admin panel better think if it will break something.

Before the Modernize or die times as promoted by Ortus Solutions there were many ways to find out in Coldbox if all input variables existed. Let me give these two JSON examples, both are used for the creation of a user in the body of a post request:

//first example, customer_id as a null value because customer is not selected yet
{
    "customer_id": null,
    "username": "wdb",
    "password": "topsecret"
}
//second example, customer_id omitted because customer is not selected yet
{
    "username": "wdb",
    "password": "topsecret"
}

When we post this userdata, I want to validate if my customer_id is there so I can populate some required customer field. When null support is not enabled we have a few options to check if we have a usable customer_id.

function createUser( event, rc, prc ) {
  //option 1
  if ( event.valueExists("customer_id") ){
    //....
  }
  //option 2
  if ( structKeyExists(rc,"customer_id") ){
    //....
  }
  //option 3
  if ( !isNull(rc.customer_id) ){
    //....
  }

The first options seems to make sense. Event.valueExists is a way to check if my customer_id is a value in my request collection.
The second options is slightly more low level, it just checks the request collection for the existence of customer_id.
The third option is a little bit more direct. It just checks if rc.customer_id is not null so I can continue.

So it seems it doesn’t matter which method I use. But now I enable full null support, and the whole landscape is changing. In the previous part I just assumed the key should be there, or not be null.

But now I have to know what my frontEnd VueJS developer is doing. Is he sending a null value for customer_id if there is no customer selection yet? Or is he only sending values in the JSON body which already have a value? This will make a lot of difference .

If my frondend developer is sending null values and I enable null support in CFML my event.valueExists and StructKeyExists() checks are completely useless, because my customer_id variable now does exist in the request collection. The problem here is it’s value is useless, because I can’t retrieve a required customer based on a null value. So the only safe check now is the !Isnull(rc.customer_id) .

The situation is still a bit different if you also want to be able to update a database based on the input of a null value. In that case you have to check for both Event.ValueExists AND IsNull.

The above examples seem quite trivial, but a word of warning is appropriate here. You really have to know how your frontend application should handle these null values. Are you validating ALL properties, or only the properties which have been entered by the user?

A second important point is the handling of nulls in some of your supporting libraries. We failed a lot of tests because one of our libraries tried to determine the datatype of our input automatically. Since null values have no datatype the library failed. This was fixed very soon, but especially when using some older libraries or modules you really should take a close look at the code when possible.

Order of elements in a qb array of structs

January 14, 2020 / / 0 Comments

Recently someone asked in the coldbox Slack channel if the keys of a struct are always accessed in the same order. The answer is usually no , but if you know which keys are present it is quite simple to access them in the right order. But if you really want the keys in a fixed order you can create your structs this way:

MyOrderedStruct= structNew( "ordered");

Although the key order is seldom important we encountered such a case. We were building a control panel in VueJS where we displayed a list of DNS records based on a JSON array of structs.
These records can be exported to a comma delimited file, but since we were doing the export in some standard Vue component we were limited in the output format of the file. Keys showed up in the same order as in the JSON structs, which was undesirable for our clients.

Our output was based on a qb (QueryBuilder) query were the results were returned as an array of structs. Let’s say we were querying for id and name in our query, e.g:

return qb.from("records")
  .select("id,name")
  .get()
//wen serializing to json the result might look like this
//but we want id,name order instead of name,id
"data": [
      {
          "name": "SomeName",
          "id": "297A83FD-1715-416F-801B-44BE1743443A",
      },
      {
          "name": "Another item",
          "id": "892FECBC-84FA-4C5E-B494-525C3712F6A2"
      }
]

If we want to change the order of the struct keys we could do some mapping on the array, e.q.

return items.map(function(item){
  var newitem = structNew( "ordered" );
  newitem.id = item.id;
  newitem.name = item.name;
  return newitem;
});

but this is quite inefficient for larger datasets. Qb is converting all queries to an array of structs, and we are creating structs again based on the qb results. Fortunately qb has a handy feature where you can define your own output format. In this case the queries in qb are directly converted to an array of ordered structs. The following code snippet was suggested by qb author Eric Peterson. Thanks Eric!

// CF2016+ and/or Lucee 5+
moduleSettings = {
    qb = {
        returnFormat = function( q ) {
            return queryReduce( arguments.q, function( acc, row ) {
                var rowStruct = structNew( "ordered" );
                for ( var columnName in q.columnList ) {
                    rowStruct[ columnName ] = row[ columnName ];
                }
                acc.append( rowStruct );
                return acc;
            }, [] );
        }
    }
}

Inserting NULL values in qb

December 1, 2019 / / 0 Comments

I can highly recommend the qb library for all kind of database manipulations, for querying and data definitions. Qb hides a lot of complexities for database actions, and abstracts away differences between database engines.

Although very powerful, some options are really well hidden in the documentation or the source code. Recently I wanted to update a database table with null values. The normal syntax for updating values in a database table is:

query.from( "users" )
    .update( {
        "email" = "foo",
        "name" = "bar"
    } );

If you have more complex requirements like inserting date values in the correct formats, you can specify query param options, e.g

query.from( "users" )
    .update( {
        "email" = "foo",
        "name" = "bar",
        "updatedDate" = { value = now(), cfsqltype = "CF_SQL_TIMESTAMP" }
    } );

This query param syntax comes in handy when inserting NULL values. As we all know older versions of Adobe Coldfusion and Lucee can’t handle null values very well:

query.from("user")
		.whereId( 10 )
		.update( {
			manager_FK = { value = "", null=true },
		} )

If you are using Lucee with full Null support you can leave out the null parameter, e.g

query.from("user")
		.whereId( 10 )
		.update( {
			manager_FK = { value = null },
		} )
« Older posts Newer posts »

© 2020 ShiftInsert.nl

Theme by Anders Noren — Up ↑