dustball / gping.io Goto Github PK
View Code? Open in Web Editor NEWgping.io
License: Apache License 2.0
gping.io
License: Apache License 2.0
at minimum this should include e-mail and password so that we can process logins
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.
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
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.
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:
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
user_devices
table)Blocked until #21 is complete since we need to know what is necessary to delete existing data.
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.
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.
Stop using mysql_real_escape_string
to ourselves from injection. We shouldn't do that and should switch to prepared statements.
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.
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
Reading location data should be possible but only for the user that is associated with the device writing it
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
.
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.
Waiting on description of their environment
Once we have the ability to authenticate users we should be able to push location and obd data for a that user
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.