Just pushed an update.
I originally misunderstood how the docker entrypoint worked with the database. In order to update your database schema with the latest changes, a new file: migrations.sql is required. I also had to make changes to the compose file to accommodate this. Please download the migrations.sql from the GitHub repository and make sure that you edit your compose file to add the new sections under "db", as seen in the latest version in the repository (added a volume for migrations and a command section that will perform the update). After this, the update procedure is the same: docker compose down, docker compose pull, docker compose up -d. All of the data in your database will remain intact.
HomeAssistant:
I spun up a HA instance to test this, and as far as I can tell, It is working now. I spent quite a while trying to get a more robust solution to work, but ended up back at the IP whitelist in the end. There is now a HomeAssistant section in the settings page that will let you add IP addresses to bypass the authentication. Note that these IPs are the devices that you use to access your HA webserver, not the HA IP itself. It will also only bypass when viewing through your HA dashboard. i.e. If you whitelist a device, it will be able to use the app inside of HA without logging in but must still log in if accessing the app directly / not through HA. If I understand the use case correctly, this should be a pretty functional solution for most people.
It definitely isn't rock solid from a security perspective (the IP can easily be spoofed), but I would actually expect it to be fairly OK for what it needs to protect against. You never know what strange stuff / dubious backdoored IOT devices might be lurking around on your network. This is, of course, especially true for HomeAssistant users. While this is still security by obscurity, I'd wager that the odds of a malicious IOT device or crawler figuring out which IPs you are allowing, spoofing one of those IPs, and simulating an iframe are virtually zero, aside from a targeted attack. None of this even matters at the moment since the app isn't using HTTPS yet, but I'm trying to future-proof / plan ahead where I can and not be the cause of any security incidents.
A note on vehicle description & Public data:
Someone mentioned the idea of integrating some public data sources to look up plates. While this would be super useful, in practice, it just isn't reliable at all. I do quite a lot of web scraping/osint/working with data brokers day to day, and license plates are among the hardest to get good data for. DMV data isn't public, so you have to rely on other sources, which there are plenty of, but the issue is that license plates just change too frequently, and there's a massive delay to get up-to-date results. With a VIN number, you can almost always find the vehicle info, but between sales, registration/state changes, vanity plates, specialty plates, etc., it ends up being really tough to keep track of.
If anyone is curious to test results on their local traffic, Oreilly Auto Parts actually lets you look up any plate for free:
I don't think it makes sense to try to integrate any lookup functionality like this since the result percentage is so low, but I'm sharing that as a resource. It has come in handy a couple of times for me when looking at nighttime footage where I didn't have any legible video to see the make/model of a vehicle of interest.
On this note, the vehicle description column has been removed from the front end since it serves no purpose at the moment.
@Vettester @prsmith777 @Skinny1
- Added camera name column to live feed. Optionally send with "camera":"&CAM" or &NAME for long name.
- Additional sorting options in plate database
- Auth bypass for HomeAssistant dashboards
- Database migration fix (Requires new migrations.sql file from GitHub)
- Ability to correct or edit OCR responses in the live feed page
I originally misunderstood how the docker entrypoint worked with the database. In order to update your database schema with the latest changes, a new file: migrations.sql is required. I also had to make changes to the compose file to accommodate this. Please download the migrations.sql from the GitHub repository and make sure that you edit your compose file to add the new sections under "db", as seen in the latest version in the repository (added a volume for migrations and a command section that will perform the update). After this, the update procedure is the same: docker compose down, docker compose pull, docker compose up -d. All of the data in your database will remain intact.
HomeAssistant:
I spun up a HA instance to test this, and as far as I can tell, It is working now. I spent quite a while trying to get a more robust solution to work, but ended up back at the IP whitelist in the end. There is now a HomeAssistant section in the settings page that will let you add IP addresses to bypass the authentication. Note that these IPs are the devices that you use to access your HA webserver, not the HA IP itself. It will also only bypass when viewing through your HA dashboard. i.e. If you whitelist a device, it will be able to use the app inside of HA without logging in but must still log in if accessing the app directly / not through HA. If I understand the use case correctly, this should be a pretty functional solution for most people.
It definitely isn't rock solid from a security perspective (the IP can easily be spoofed), but I would actually expect it to be fairly OK for what it needs to protect against. You never know what strange stuff / dubious backdoored IOT devices might be lurking around on your network. This is, of course, especially true for HomeAssistant users. While this is still security by obscurity, I'd wager that the odds of a malicious IOT device or crawler figuring out which IPs you are allowing, spoofing one of those IPs, and simulating an iframe are virtually zero, aside from a targeted attack. None of this even matters at the moment since the app isn't using HTTPS yet, but I'm trying to future-proof / plan ahead where I can and not be the cause of any security incidents.
A note on vehicle description & Public data:
Someone mentioned the idea of integrating some public data sources to look up plates. While this would be super useful, in practice, it just isn't reliable at all. I do quite a lot of web scraping/osint/working with data brokers day to day, and license plates are among the hardest to get good data for. DMV data isn't public, so you have to rely on other sources, which there are plenty of, but the issue is that license plates just change too frequently, and there's a massive delay to get up-to-date results. With a VIN number, you can almost always find the vehicle info, but between sales, registration/state changes, vanity plates, specialty plates, etc., it ends up being really tough to keep track of.
If anyone is curious to test results on their local traffic, Oreilly Auto Parts actually lets you look up any plate for free:
I don't think it makes sense to try to integrate any lookup functionality like this since the result percentage is so low, but I'm sharing that as a resource. It has come in handy a couple of times for me when looking at nighttime footage where I didn't have any legible video to see the make/model of a vehicle of interest.
On this note, the vehicle description column has been removed from the front end since it serves no purpose at the moment.
@Vettester @prsmith777 @Skinny1
Last edited:
