[Ovmsdev] OVMS HTTP Protocol

Fri Jun 13 00:35:47 HKT 2014

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 at 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 at 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 at 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 at 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 at mainpine.com | www.mainpine.com <http://www.mainpine.com>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140612/4e6b457f/attachment.htm>