[Ovmsdev] OVMS HTTP Protocol

Sun Jun 15 01:50:45 HKT 2014

Mark,

I just tried connecting via HTTPS and got this:

tom$ curl -s -X GET -c ~/Downloads/ovms-cookie -v
"https://tmc.openvehicles.com:6969/api/cookie?username=USER&password=PASS"
* Adding handle: conn: 0x7fd343804000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fd343804000) send_pipe: 1, recv_pipe: 0
* About to connect() to tmc.openvehicles.com port 6969 (#0)
*   Trying 64.111.70.40...
* Failed connect to tmc.openvehicles.com:6969; Connection refused
* Closing connection 0

The same thing works as expected using http://tmc.openvehicles.com:6868/

Am I doing something wrong?

   Tom

On 6/12/14, 10:23 PM, "Mark Webb-Johnson" <mark at webb-johnson.net> wrote:

Tom,

The code does support HTTPS (port 6969). I've just been too lazy to get a
cert for tmc.openvehicles.com <http://tmc.openvehicles.com> . I'll handle
that.

Regards, Mark.

On 13 Jun, 2014, at 12:35 am, Tom Saxton <tom at idleloop.com> wrote:

> 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 <http://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.hkhttp://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/20140614/313961a6/attachment.htm>