[Ovmsdev] Open Charge Map

[Christopher Cook]

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