I agree that moving to OATH for the HTTP protocol would be great, but we could make a huge improvement in security by simply switching to using HTTPS on tmc.openvehicles.com. I just did that for a site I built and administer, it was easy and inexpensive, $50 per year. For my PHP site, it was all just server config stuff and totally invisible to the code. Two small improvements I'd be happy to work on when Mark is done with his work: 1. Use POST instead of GET to log in so URLs with usernames and passwords don't get stored in local and server logs. 2. Add a timestamp parameter to the methods that retrieve charge, drive, and server logs to only retrieve records with that timestamp or larger. In order to retrieve new records, I have to download all records, which means 130K of transfer when I really only need a tiny fraction of that. Tom On 6/11/14, 10:19 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote: Chris, Lee, Here's an overview: 1. The 'raw' protocol is a binary protocol car<->server and server<->apps. The same protocol is used for both, with the server primarily being a relay with store-and-forward capabilities. The protocol itself is binary, but the data transmitted looks more like CSV records. 2. 3. 4. The current vehicle module uses the raw protocol to talk to the server. 5. 6. 7. The current iOS and Android apps use the raw protocol to talk to the server. 8. 9. 10. The raw protocol uses a vehicleid+serverpassword authentication scheme, where the serverpassword is a shared secret between the vehicle, server and apps, and is used for both authentication and encryption. The raw protocol also supports a 'paranoid mode' where a second modulepassword is used in the apps and vehicle module to double-encrypt the data so that even the server cannot decode it. 11. 12. 13. There is an experimental HTTP protocol (API) that runs on the server and is used to read the vehicle data and communicate with the vehicle. We want to use this as the basis for future apps. With this api, the data returned is in JSON format and is structured as human/machine readable (for example 'SOC', rather than 1st field in the 'D' message). 14. 15. 16. The HTTP API currently uses OVMS username+password for authentication, and returns an authentication cookie. That is fine for experimental use, but suffers when trying to get third parties involved (as the user would need to give their OVMS username + password to the third party for storage). We would like to migrate that to an OAUTH style scheme. 17. 18. 19. It seems sensible to use a variant/extension of the HTTP API for this work on charge event distribution. The OVMS www.openvehicles.com <http://www.openvehicles.com> site is in PHP (Drupal) and the OVMS server itself is in perl (AnyEvent and AnyEvent::HTTP based). My issue is (a) time, and (b) lack of experience with OAUTH. We would presumably need an OAUTH server (either within the OVMS server or hosted by www.openvehicles.com <http://www.openvehicles.com> ), and an OAUTH capability within the HTTP API on the OVMS server. Quite frankly, I am not sure where to start with this. I've read the background documents, and have an understanding of what is required, but it is very hard to find implementation examples that make sense for what we are doing, in Drupal/PHP or Perl. Regards, Mark. On 12 Jun, 2014, at 12:58 pm, Christopher Cook <christopher.cook@webprofusion.com> wrote:
Yes, sounds like it to me. So the OVMS web side needs help implementing OAUTH so that other app/services can make authenticated requests to the server over HTTP.
I believe from my quick glance over it that the main server protocol is currently binary encrypted comms over UDP which is generally both harder to parse, impossible to use from a browser client (no UDP) and presumably more difficult to extend for operations unrelated to streaming car state.
I assume the http API is php? Not really my bag but I'm sure there are plenty of oauth modules/libraries for you to choose from. Assuming you need OAuth 1. OAuth 2 always requires presenting the user with an authentication page which isn't ideal for server side stuff.
Chris
Lee Howard <lee.howard@mainpine.com> wrote:
If I understand correctly, the GPS data is sent from the module in the car encrypted through the server to the handheld app. (Correct?) Or maybe that was outdated information that I read (README files in the code). Hence, I do not understand how OCM would reliably "pull" data from either the module or the app. A "push" from module to OCM seems burdensome and inappropriate.
So, if the GPS data is encrypted all the way from the module to the app, then I can really only sensibly imagine the app pushing data to OCM.
I must have misunderstood or read outdated information in the READMEs... because it seems much more-sensible for OCM to be communicating with the OVMS server... whether it be a push or a pull. But... if the data is encrypted passing through the server... then that's out of the question.
And, I presume, then, *that* is where you are looking for help: implementing the authentication model on the OVMS server. (?)
Thanks,
Lee.
On 06/11/2014 05:25 PM, Mark Webb-Johnson wrote:
Where I'm really looking for help is the authentication model for the HTTP API. What we have now is kludgy, and it would be good to support OAUTH.
Regards, Mark.
On 11 Jun, 2014, at 5:25 am, Lee Howard <lee.howard@mainpine.com> wrote:
Mark,
Has there been any work done in regards to submitting charging data out to OCM? I'm ready to start tinkering on this, and if some work is already being done then I want to attempt to do so collaboratively.
Thanks,
Lee.
On 05/23/2014 01:19 AM, Mark Webb-Johnson wrote:
So, given that we will be giving away¹ the data, it comes to the black box¹ question of how to do that. My own personal preference is just to provide an api to either PUSH or PULL the data, and the reason for that is I don¹t want to be extending the server code to support ten different third-party APIs. That said, I did suggest a PUSH option in the original RFQ, and the thinking behind that is we can format a URL+formdata with parameter-substitution (based on server.conf settings for a particular provider - no code) and just fire it off. I see no problem with a single API key for OVMS to submit to such an external service. For user credit¹, it would be nice to have an option where the user could enter an optional username+pin for each service, and we can provide it as part of the PUSHed/PULLed data.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com <http://www.mainpine.com> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev