dustball / gping.io Goto Github PK

It seems poor form to rely on .htaccess for protecting vendor-composer, api, and (soon) our own lib directories. Ideally we would move these things out of /var/www/html which will require updates of the container construction and non trivial documentation to all READMEs.

If this seems unnecessary I'm happy to have some push back.

Once we have the ability to authenticate users we should be able to push location and obd data for a that user

Waiting on description of their environment

We should be thinking about how to handle authentication for devices. It doesn't really come into play until #21 but a likely method would be to just generate a JWT with device_id claim that includes the unique ID then use that as auth.

Reading location data should be possible but only for the user that is associated with the device writing it

Currently our "dashboard" is limited to "here is a map for some vehicle id" which is neat but limited. With the addition of user accounts we need to rework the web app to support user creation/auth, account/device settings, and (single/multiple) vehicle mapping.

Currently we only expose a single device per user and have no real user settings but our UX needs to be able to gracefully extend to supporting more than this.

Needs to mark a device as no longer valid for positional data.

We should be able to delete in two ways

1. Delete but retain data i.e. soft deletion; this will retain the device location data but will mark the object as deleted for the purposes of receiving new data (probably means new bool in user_devices table)
2. Delete and purge data is straight forward and should just remove the device and all positional data associated with that id.

Blocked until #21 is complete since we need to know what is necessary to delete existing data.

We have a functional workflow for @falun & @dustball but since we're starting to open source the service half we should make explicit a few things:

1. What the contribution review process looks like (e.g. expect code review, is there a style guide?)
2. How do features work that require service and app (not open sourced) changes
3. What is the prioritization process for feature requests
4. For larger collections of work how do we track it
5. other stuff?

Previously there was a pretty trivial breakdown of the system -- read.php read from the DB and write.php wrote to the DB.

Things are a little more complex now and it'd be nice to capture how things work. Not looking for something super detailed as it'll remain continue to shift for a while but getting a start on how we deal with request routing and what the major DB read/write functions are would be nice.

Basically fill out docs/www.md.

echo just doesn't cut it any more.

Need to add a logging library and make it configurable. The problem here is finding a good balance between simplicity (of use & config) and flexibility.

This should include updating docs/Production.md or linking from it to a doc describing logging solution.

Providing this argument via post body ({"device_type": "vehicle"}) or path param (POST api/v1/<user>/device/<type>) are both okay.

Slight preference to path param

We need some way to validate requests as coming from a specific user without forcing a user/pass sent on every request.

At one point we had a guide to run this without docker in the mix -- that is still valuable and needs docs added back as an alternative

Stop using mysql_real_escape_string to ourselves from injection. We shouldn't do that and should switch to prepared statements.

From PHP.net:

It is recommended to use either the mysqli or PDO_MySQL extensions. It is not recommended to use the old mysql extension for new development, as it was deprecated in PHP 5.5.0 and was removed in PHP 7

We're currently using the old style mysql interface and I'd like to move to PDO.

should cover v1/<user>/device/<device id> as well as v1/device/<id> and should aim to leverage as much of the same code as possible.

This might be a good time to make our endpoint controller mapping a bit more clever.

at minimum this should include e-mail and password so that we can process logins

Basically I tried something that was (maybe?) dumb and results in unexpected failures wrt defined variables. The question of whether these variables should be defined / used as they are is another question but I don't like it when code bases surprise you and the thing I was going for can be better handled with autoloaders anyway.

Anyway, switch from load to require_once(dr(...)); or if we (you) have better approach to require/include policy propose that and move to it.

Currently the DB works by re-imaging itself on every docker initialization. That works for now but leaves a lot to be desired as the schema starts evolving and we need to push changes to the prod DB.

This should include updating docs/Production.md or linking from it to a doc describing migration solution.