One project every month - making stuff better ...

Completing JWT_NINjA for full JWT support

In the single blog post I wrote on the JWT_NINJA package back in June last year, I ended the post by saying that I needed to implement both a verify and a parse function for the package.

Well, it took me a year, but I finally had a reason to go and implement it. As I am getting into Oracle ORDS and trying to get some experience in building REST services, I want to be able to use JWT as the token generator for the application that I am building.

So a quick refresh on how to generate a token using the package:

select jwt_ninja.jwt_generate(p_signature_key => 'my secret password', p_reg_claim_issuer => 'My Application', p_reg_claim_subject => '147654') as token from dual;


So now that we have a token, we would store that on the client side, and every request from the client would include this token for us to validate. So to validate the token there is now a procedure jwt_ninja.jwt_verify_and_decode that will do just that. The third argument (p_do_parse) indicates if you only want the token to be verified or if you want to parse the fields inside the payload. The default is to only verify the validity of the signature and the message and not do the parse. If it is set to true, the values of the different JWT claims will be set and found in the output parameters of the procedure.

  mysecret varchar2(4000) := 'my secret password';
  mytoken varchar2(4000) := jwt_ninja.jwt_generate(p_signature_key => 'my secret password', p_reg_claim_issuer => 'My Application', p_reg_claim_subject => '147654');
  doparse boolean := false;
  myresult boolean;
  l_reg_claim_issuer      varchar2(4000) := null;
  l_reg_claim_subject     varchar2(4000) := null;
  l_reg_claim_audience    varchar2(4000) := null;
  l_reg_claim_expiration  date := null;
  l_reg_claim_notbefore   date := null;
  l_reg_claim_issuedat    date := null;
  l_reg_claim_jwtid       varchar2(4000) := null;
  jwt_ninja.jwt_verify_and_decode(mytoken, mysecret, doparse, myresult, l_reg_claim_issuer, l_reg_claim_subject, l_reg_claim_audience, l_reg_claim_expiration, l_reg_claim_notbefore, l_reg_claim_issuedat, l_reg_claim_jwtid);
  if myresult then
    dbms_output.put_line('Iss: ' || l_reg_claim_issuer);
    dbms_output.put_line('Sub: ' || l_reg_claim_subject);
    dbms_output.put_line('Not verified');
  end if;

So know I can "close" this codemonth for now, since I can start to use it in my other project.

Take a random REST

I needed to test ORDS for some webservice related projects at work. So I decided to build a rest interface for all the different random data functions in the RANDOM_NINJA package to test out, just how easy it is.

First order is to setup ORDS. Like always Tim over at oracle-base have a couple of really good articles on installing and setting up ORDS itself. So no need for me to duplicate that.

After setting up ORDS, and enabling my schema for rest services like in this oracle-base article, it is time to enable the functions in the different data domain packages. I decided to keep the URL scheme simple, so that the path would be /[package_name]/[function_name]/ for any of the functions that are part of the RANDOM_NINJA package.

Generating randomized incremental values

In the previous entries, I explained the basics of testdata_ninja and then I explained how to create foreign key relations between your test data and existing tables. This time I will show how you can create data that are random but always increasing, either to create time patterns or to create unique id columns for primary keys. I will extend the format that I have already used in the previous entries, so the code will be familiar. If we look at the output of the test_days generator we have created, it currently looks like this:

SQL> select * from table(tdg_test_days.test_days);

NAME                                               BIRTHDAY            MY_PK_REF
-------------------------------------------------- ------------------ ----------
Arianna Turner                                     02-MAR-93 00:24:58          1
Sofie Dam                                          17-MAY-91 17:21:09          1
Camila King                                        27-OCT-62 18:16:56         10
Malik Henriksen                                    24-NOV-65 06:23:51         10
.... [more rows] ....
There is no clear column with possible unique values, so I will create a new column where the data generator is an "incrementor". Like all the other different data fields, it is in the 3 field definition of the block that we define how to generate the data. So far the format looks like this:

So let us add a column in the beginning, that increments randomly but is unique nonetheless:

and here is the explanation of the fields, which are separated by the "~" character:
  • incrementor type (numiterate for numbers and datiterate for dates)
  • start from (number or date to start increment from)
  • increment range (for numbers min and max separated by the "¤" character and dates interval type (seconds, minutes etc), min and max separated by the "¤" character for example: seconds¤1¤5)
So if we now take a look at the full format in the code, it would look like this:

  the_format varchar2(4000) := 'people_pk#number#^numiterate~1~3¤5@name#varchar2(50)#person_random.r_name@birthday#date#person_random.r_birthday@my_pk_ref#number#£t_people¤person_num_pk¤simple¤5';
  testdata_ninja.generator_create('test_days', the_format);
And would create a result like the following:

1	Sigurd Andreasen	20-NOV-63 12:33:49	1
6	Ella Madsen	30-JAN-80 07:09:39	1
9	Alexandra White	16-JUL-53 16:32:07	1
13	Benjamin Holst	08-APR-88 13:39:38	1
17	Lea Jepsen	24-MAY-88 17:21:01	1
21	Eli Morgan	07-AUG-86 15:54:27	10
26	Oskar Bruun	20-JUL-69 22:40:56	10
31	Jens Friis	26-APR-63 16:32:21	10
35	Camila Hall	05-DEC-78 23:30:19	10

Test data and foreign keys

In my last entry on testdata_ninja I showed the basics on how to create your own custom test data generators.

Once you have created the simple ones you probably want to extend it a little bit, and create test tables that has relations. So you want to create random data, but random data that actually can join to another table. The way to do this, is with a special data generator construct in the testdata_ninja format. If you read the old entry, you can see that testdata_ninja format is a series of columns seperated by the "@" sign. Each column has at least 3 parts (divided by the "#" character), where the third is the data generator.

So in the previous example I wrote about we used functions from the random_ninja package. You can however, reference existing tables instead. First we want to create a master table that we can reference in our new generator. We will use the basic data generators that are already part of the testdata_ninja package to create this:

create table t_people as select * from table(testdata_generator.people(100));
This statement will create a table with a hundred rows in. This table is what we will use to create our other test data table. One of the rows is called person_num_pk, and that is the column with the relation to our other table. The way we define that is with a special character as the first character in our generator field. So in my last entry I defined the test table with the following format:

So let us say that I wanted to add another column here, that linked to my primary key in the new table I just created. If I wanted to do that I simply create a third column definition like the following:

Notice the "£" sign. This is what specifies this generator as a reference to another table and not a function. The fields in the reference generator (divided with the "¤" character) are the following:

  • table name that we are referencing (t_people)
  • column in that table we are referencing (person_num_pk)
  • distribution rule (simple or range)
  • distribution count. If simple just one number, and every ref will this many rows in the new generator or range and you specify 2,5 then every reference will have between 2 and 5 rows in the new generator
So to create this new table we would simply run:

  the_format varchar2(4000) := 'name#varchar2(50)#person_random.r_name@birthday#date#person_random.r_birthday@my_pk_ref#number#£t_people¤person_num_pk¤simple¤5';
  testdata_ninja.generator_create('test_days', the_format);
and we can now select from the generator and see that each value in the my_pk_ref column will be a real reference back to the t_people table and there will be 5 "child" rows per real row from the t_people table:

  , b.birthday
  t_people a
  , (select name, birthday, my_pk_ref from table(tdg_test_days.test_days)) b
  a.person_num_pk = b.my_pk_ref;

FIRST_NAME                                                                                           BIRTHDAY         
---------------------------------------------------------------------------------------------------- ------------------
Parker                                                                                               14-SEP-64 13:35:56
Parker                                                                                               18-APR-62 05:02:35
Parker                                                                                               05-SEP-93 12:35:50
Parker                                                                                               16-AUG-82 21:19:14
Parker                                                                                               11-MAR-85 15:51:54
Bryson                                                                                               03-SEP-84 19:56:20
Bryson                                                                                               08-JUL-96 14:33:07
Bryson                                                                                               30-DEC-62 06:28:59
.......... [more rows]

Creating real test data - Fast and Efficiently

When I build RANDOM_NINJA I knew already one of things I wanted to use that library for. Building good valid and life-like test data has and is always a really big problem. The base for good test data is good and valid looking random data. Without that, most tests are not really valid, as data can be clustered wrongly, indexes act strange because data does not mimic real life and relations and constraints are hard to define or validate on data that is created using most available randomizing packages. That is why it was important to me that RANDOM_NINJA would be able to create random data from as many different domains as possible. As of today it can create more than 185 different data points from as many as 14 different data domains.

But having good random data is only half of it. You still need something that can define and create those tables. You also need something that can still maintain relations between those test tables, and make sure that foreign key distributions are real as well. So I created TESTDATA_NINJA. This package has some generic generators to create simple tables of people, populations which are true according to UN demographics data, CDR records and credit card transactions. The real function in this package is the custom generation procedure. This procedure can parse a string representation of what your data looks like and from that create pipelined functiones that can create thousands of test rows extremely fast and efficiently.

The testdata_ninja.generator_create procedure takes 2 arguments. The name of the new generator and the format of the test data. Below is a short description on how the format looks like.