BioTrackTHC User Account Bugs

There is a huge bug in the BioTrackTHC API in Washington (and NM, HI, IL). We’ve raised this issue with both the WSLCB and with BioTrack and yet BioTrackTHC refuses to address the issue at all. Even worse, if you are affected by the bug BioTrackTHC refuses to help.

Reproduction:

From the BioTrack API it’s possible to adjust user permissions, with a fairly granular set of permissions including: user_add and user_modify permissions. Using an “Administrative” level account it’s possible to lock yourself out by removing these permissions from your administrative level account! Of course, other (smarter) software prevents this from occurring, by enforcing that at least one account remain with full permissions (eg: Google Apps, Microsoft Windows). What’s even worse for third-party integrators there is no method to determine which account has these permissions so that our software could out-smart the issues in BioTrash (a nickname folks in Washington have given to the software).

From the limited software that BioTrackTHC provides to the State this granularity is not visible but the bug still is present it just happens in with a different UI. Simply sign in, then modify your user to remove the ‘Admin’ privilege using the checkbox. Boom, you’ve locked yourself out, with no way to restore.

To add insult to injury if you ask the LCB to fix the issue they don’t have the proper control and must ask BioTrack. BioTrack’s response is basically: “too bad, it must be a bug in the third party software”.

And the root cause of all is this is because BioTrack API is designed to require the use of the same username and password as the human sign in – a known “worst practice” of software design.

Of course, we’ve already observed that BioTrack doesn’t follow best practices, or fix their bugs.

Categories: API
Tags: , ,

Data Anomaly in Public Records

Through the Freedom of Information Act we are able to obtain database dumps from the Washington State BioTrack database. Here’s a small anomaly we’ve noticed on this one.

Keep in mind, this is a system that is supposed to guarantee unique identifiers for all plants and inventory and provide robust tracking.

select id from inventory group by id having count(id) > 1;
0214523902408153

Everyone knows that quality database systems don’t enforce unique indexes on their system.

We reported this issue originally in Sept 2015 and again in Aug 2016.

BioTrack/WA – Phantom Inventory on Adjustments & Derivatives

Yet another data inconsistency in the BioTrackTHC system for Washington State.  In this case we see the system indicate an Inventory Adjustment – but there is no corresponding record to the Inventory itself.  Either the original Inventory records have been dropped from sync, or the Adjust data-set is improperly including this one.

{
 "atype": 4,
 "inventoryid": "9385560946883972",
 "location": "412457",
 "new_quantity": "0.000000",
 "previous_quantity": "2187.902796695",
 "reason": "Originally entered with stems and once reprocessed to remove them, the system was not updated to reflect the loss in tonnage. The stem are located at the property.",
 "sessiontime": "1456962584",
 "transactionid": "23108927",
 "transactionid_original": "23108927"
}

Fortunately we can discover from the Public Records what is the situation here. The original inventory item in question (9385560946883972) is still connected to a previous license location ID (#1771) . However, many other records in the system (such as the Inventory Adjustment) have been modified to reflect they are part of the business that took over! So, most (but not all) of the records were updated to reflect location (859).

What BioTrack did here was to move some records to the newly created location record (#1771) to reflect the data about the business that was closing. Then location #859 was modified to reflect the updated name, license and UBI. Then some (but not all) plants and inventory were assigned to the new location (and organisation) records representing the closed business.

And now, data being shared through the BioTrackTHC API is incomplete – due to the incomplete handling of the records above.

Another aspect to this issue is that also Plant Derivative items are referencing Plants that were not properly moved to the new license (or the Derivative’s were improperly moved).

Either way, it’s inconsistency and sloppy data handling and these issues affect more than just Washington.

BioTrackTHC Cross-State Data Contamination

Today we’ve observed some serious issues with the BioTrackTHC API in New Mexico.  These issues clearly indicate their system is not tested or audited for integrity.  If BioTrackTHC cannot tell the difference between New Mexico and Washington State how can we trust the other data in their system to properly track marijuana?

Manifest with Orphaned Vendors

First what we see is Manifests that indicate they’ve been delivered to Vendors that don’t exist.  In this case the Vendor in question doesn’t exist in the system at all and the Manifest data has empty values for the delivery Name, Phone City, Address and Zip and the State is defined as “WA” – which is not “NM” as expected.

Manifests with Incorrect States

A secondary issue here is that nearly 100% of the Manifests discovered from the ‘sync_manifest’ API show the delivery State to be “WA”.  However the Vendor records (when they exist) indicate the correct State.  Perhaps BioTrackTHC is hard-coding data in their system?

Data Integrity

BioTrackTHC claims to have the best system on the market for marijuana tracking – however they cannot even get the State correct in their data.  This calls into question the accuracy of their entire system.

BioTrack API Update 1.18 – Another Fail

Today BioTrackTHC+WSLCB released another update to the API; again with zero advance notice for third party integrators.  At the end of Friday an announcement was provided which details the changes.  This leaves integrators (such as WeedTraQR) in the lurch.  Now, we have to work through the weekend to integrate these critical updates.

On multiple occasions WeedTraQR has communicated to both BioTrackTHC and the WSLCB how to deploy updates to an API.  Announce the coming changes; provide a deployment timeline and updated documentation.  Then deploy on the schedule allowing integrators time to catch up.

Some have speculated that there could be malicious intent on the part of BioTrack.  The malicious intent theory is that BioTrash would use this intentional non-communication as advantage; ie: “Only our software works with our secret API”. These updates occur “at the last minute” and only their systems are ready.  Of course! They control the backend! They knew these changes were coming and could plan ahead.  I’m simply asking for the same.  Every other company that is providing APIs also provides advance notice.

These are just more stories about how BioTrack is a poor technology provider and another example of how a State agency cannot enforce good behavior on the part of their selected vendor.  The need for more open systems has never been more apparent.

We’ve just asked BioTrack and the WSLCB:

Why do you continue to make modifications and release updates w/o any advance notice for third party integrators? I’ve informed your organisation multiple time how to handle this properly yet you continue to ignore the advice. This behavior continues to directly harm businesses in Washington State. You should be ashamed of these sloppy practices.

We’ll update with any response we receive.

Response from BioTrackTHC

Their Chief Software Architect (“TJ”) replied with this:

Hi David,

Regrettably, as a security precaution, I do not click on strange links, so I am unsure as to what the content of your blog article contains.

While I understand that both of the employees in your company are working hard to provide advice to the industry on best practices; I would suggest you do your own research on best practices and how we have actually exceeded those in the technology industry.

A quick reading of the API shows that there have not been any version breaks since inception, unless required by statute. This behavior continues to directly benefit businesses in Washington state and I am very proud of the immaculate practices we have followed in doing so.

 

BioTrackTHC API Security is a Fucking Joke

The authentication system for this API is a fucking joke. Rather than use established standards like oAuth or hash-tokens they require that users of the API use the SAME CREDENTIALS that are used to sign-in to their system. This is a KNOWN ANTI-PATTERN in the technical world for many reasons.

It’s problematic because it requires integrators to keep this password on file. If there were any security issues in the integrator platform it could expose this BioTrack credentials.

It’s completely stupid to have users share their username/password with integrators. Ask anyone. Every other technology company on the planet uses some kind of dedicated/unique tokens.

What BioTrackTHC Should Do

First, all integrators should be issued a unique API key. This would allow each integrator to be positively identified.

Secondly, BioTrackTHC should implement some method for users to generate a unique API token. This API token is what should be given to the integrator. In this fashion the User Account and the API access can have different permission levels and these keys can be revoked or re-issued without any impact on the User Account.

My hope is that BioTrackTHC will listen to this advice and implement this the proper way. The way that has been well defined and accepted by the technology community for over a decade.

Hey BioTrackTHC! Where’d you get your security model? 1989?

Categories: API, Traceability

BioTrackTHC API – Abrupt Change, Bad Documentation

BioTrackTHC abruptly changed their API On Saturday, May 28th with zero notice to any of the third party integrators in Washington State.

The change this time created a new value for the LocationType field of the Vendor objects. The new value is ‘9’.

BioTrackTHC also (silently) published an updated API document (https://biotrackthc.com/sites/default/files/state-docs/JSON-21.pdf). This new documentation introduces functionality for manifests to be transported by third parties. However, no mention is made about LocationType 9.

The introduction of the third party manifest might make one assume that LocationType 9 is a Distributor license and it’s awesome the the LCB is (finally) moving forward with that type of license. However, the Vendors that appear with the LocationType 9 are definitively not Distributors, as none of those licenses have been issued. Empirical data shows that these licenses are given to Native American Tribes here in WA.

Now, the BioTrackTHC web-site has removed the JSON-21.pdf and is only providing the previous version (JSON-20.pdf) which, of course, also does not mention LocationType 9.

We reached out to both the LCB and to BioTrackTHC on the 28th and have still not received a response from either party.

To recap: Abrupt, un-announced changes to the API, documentation is missing, then the documentation was pulled, no response to request for help.

Perhaps they should take a look at how Franwell is doing things in Colorado and Oregon. The documentation is excellent, feedback from developers is actually listened to, they have held in-depth technical training and provide a fully functional Test environment (which Washington still doesn’t have!). I can’t fathom how BioTrachTHC can claim to be the “the most robust seed-to-sale API in the industry”. #Bullshit

BioTrackTHC API – License Handling Modified w/o Notice

Once again BioTrackTHC has modified their API with zero notice to the third party integrator. The API in question this time is inventory_manifest_lookup. This API takes only one parameter, a six digit license ID.

Prior to May 14th, if one was to query this API using an in-active license ID it would respond with the message:

{
    "error": "No inbound transfers or pending manifests found.",
    "errorcode": "602",
    "success": 0
}

Then, the API changed on May 14th without notice. The new response is:

{
    "error": "Please specify a valid license number.",
    "errorcode": "602",
    "success": 0
}

Stupidly, the BioTrackTHC system uses the same error code; but they do that for scores of other cases.

The important thing is that now, the BioTrackTHC system finally enforces the validity of a license number – at least in one place.

There is another API call that is impacted by the validity of the Vendor License ID, that is sync_vendor.
This API call still provides invalid/inactive licenses when you query it – with no way to determine their status.

Update From BioTrack

This response from BioTrack is classic.  First they claim the API hasn’t changed; then they claim the changes were part of a project they had been working on.

The behavior of this query hasn’t changed. It’s actually identical and no API change occurred whatsoever; thus no notification was required.

While your valuable input is always appreciated; your presumption that your communications spurred this in any way, shape or form is incorrect. In fact, this was actually the culmination of a 6 month project to better communicate with a separate licensing system and more accurately account for privilege drops, license moves, license assumptions and more.

I am, however, pleased to hear you are more satisfied with the API. Considering the state of Washington is running the most robust seed-to-sale API in the industry; satisfaction is very important.

Together, we look forward to continuing to make Washington the model for all states to come.

Categories: API, Traceability

BioTrackTHC Washington – QA Results Crazy!

There appears to be a bit of a discrepancy with how the BioTrackTHC system handles the QA results.
Sometimes it shows the results are there and keeps the association with the parent ID.
In other cases that relationship seems to be lost and one must know a sub-lot of a sub-lot ID to find the results.
Oh, and in that specific case one API call shows no results and another API call does provide QA results.
WTF.

Here is a brief of the data sets we are working with for these two cases.

Case One

6035 0432 0000 0179 - Flower Lot
- inventory_qa_check_all - returns full results
	[barcode_id] => 6035043200000179
	[parent_id] => 6035043200000179
	[sample_id] => 3139613752727644
- inventory_qa_check - returns full results

	+ Sub Lot: 3139 6137 5272 7644 - the QA Sample
	-- inventory_qa_check_all - returns full results
		[barcode_id] => 3139613752727644
		[parent_id] => 6035043200000179
		[sample_id] => 3139613752727644
	-- inventory_qa_check - returns full results

Case Two

6033 5961 3000 0548 - Flower Lot
- inventory_qa_check_all - empty results
	[barcode_id] => 6033596130000548
	[parent_id] => 6033596130000548
	[sample_id] => 2067405476952591
- inventory_qa_check - "results have not yet been filed"

	+ Sub Lot: 2067 4054 7695 2591 - Flower Lot / Not Created in WeedTraQR
	- inventory_qa_check_all - empty results, points
		[barcode_id] => 2067405476952591
		[parent_id] => 6033596130000548
		[sample_id] => 2067405476952591
	-inventory_qa_check - "results have not yet been filed"

		++ Sub Lot: 9478 8580 0427 1386 - Flower Lot / QA Sample
		- inventory_qa_check_all - empty results
			[barcode_id] => 9478858004271386
			[parent_id] => 6033596130000548
			[sample_id] => 2067405476952591

Summary

In Case #1

This is the one we’re calling the normal case.

  • Parent: check_all for Flower Lot ID returns full results and pointer to a Sample
  • Parent: check routine returns result when queried by Flower Lot ID
  • Sample: check_all returns full results, points to correct parent, points to self as sample_id
  • Sample: check also returns full results

In Case #2

This is the one we’re calling the abnormal case.

  • Parent: check_all empty results; points to a sample
  • Parent: check indicates results are not filed
  • Sample: check_all provides empty results, points to correct parent and sample ID
  • Sample: check indicates results are not filed
  • Sub-Lot From Sample (1386): check_all empty results, points to correct parent, points to !self sample_id
  • Sub-Lot From Sample (1386): check returns full results

In some cases inventory_qa_check_all by Parent is returning results and in others it is not.

In some cases inventory_qa_check by Parent shows results, other times it errantly indicates results are not filed.

In some cases inventory_qa_check_all by Sample provides results; in other cases it provides empty results and NO POINTER to the actual sub-log

In some cases inventory_qa_check by the Sample Sub Lot indicates there are no results and then inventory_check_qa for the same identifier returns results.

This inconsistent method of handling QA results and the QA result relationships concerns us.

Categories: API, Traceability

BioTrackTHC Vendor Data – Missing Critical Details

For integrators in Washington (and other States) BioTrackTHC maintains the list of the vendors authorized in the system and their license numbers. This list is visible from the sync_vendor API call. However, a critical piece of data is kept out of this data-set – which licenses are active.

What this means for an integrator is that is not possible with the data provided by the system to determine which license can and should be used.

In fact in this vendor data-set historic, non active licenses are included. With no way to identify them. Here is an example, one of the two records below is not active, can you tell which one? (Note: Names and Address have been redacted)

{
    "address1": "[redacted]",
    "address2": null,
    "city": "SEATTLE",
    "location": "412252",
    "locationtype": 6,
    "name": "[redacted]",
    "processor": 1,
    "producer": 1,
    "retail": 0,
    "state": "WA",
    "transactionid": "121639",
    "transactionid_original": "121639",
    "ubi": "[redacted]",
    "zip": "[redacted]"
}
{
    "address1": "[redacted]",
    "address2": "[redacted]",
    "city": "SPOKANE VALLEY",
    "location": "419150",
    "locationtype": 6,
    "name": "[redacted]",
    "processor": 1,
    "producer": 1,
    "retail": 0,
    "state": "WA",
    "transactionid": "121535",
    "transactionid_original": "121535",
    "ubi": "[redacted]",
    "zip": "[redacted]"
}

Nope! There is no indicator which of the licenses is active. This puts third-party integrators at a severe disadvantage.

When asked about these issues BioTrackTHC responded with legal threats.

Categories: API, Traceability