[Ovmsdev] OVMS HTTP Protocol
Tom Saxton
tom at idleloop.com
Mon Jun 16 00:08:17 HKT 2014
Mark,
That works, and it shows up as being secure so you must have set up the
certificate.
Thanks!
Tom
On 6/15/14, 4:33 AM, "Mark Webb-Johnson" <mark at webb-johnson.net> wrote:
Tom,
Sorry, wrong port. Try 6868 for HTTP and 6869 for HTTPS.
This should now work on both tmc and www sites.
Regards, Mark.
On 15 Jun, 2014, at 1:50 am, Tom Saxton <tom at idleloop.com> wrote:
> 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 <http://tmc.openvehicles.com>
> port 6969 (#0)
> * Trying 64.111.70.40...
> * Failed connect to tmc.openvehicles.com <http://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.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/20140615/35d18873/attachment.htm>
More information about the OvmsDev
mailing list