[Ovmsdev] Anyone using HTTP API?

[Michael Balzer]

Mark,

I did 1b73a7f8 to split the "create & compare password" function into separate "create" & "compare" steps, and introduced the "pw_encode" config hook to be able
to supply just a custom "create" operation. That simplifies the config (see example).

That change has been working since 2016 on my server. I see you reintroduced the "create & compare" function as a separate function for the MQTT auth, but don't
see why that was needed. I also don't see why the separated function was broken on your server. Can you please elaborate? I'd like to understand what was going
wrong.

With reverting to the "create & compare", this breaks the configuration of servers not using Drupal. Essentially, the new "pw_check" hook does just the previous
"pw_encode" and adds the comparison to that, so I'd rather opt for adding a default function here that simply reuses the existing "pw_encode" hook.

Regards,
Michael


Am 20.02.20 um 04:09 schrieb Mark Webb-Johnson:
> Even stranger. This conversation obviously triggered someone to try it and then raise a support ticket that HTTP API authentication didn’t work.
>
> It seems  a change was made back in 2016-02-01 23:59:22 (1b73a7f8) that broke the pw_encode function (drupal_password). It was also weird because we had
> drupal_password and drupal_password_check functions, doing pretty much the same thing (one used by HTTP API and the other by MQ authentication).
>
> I standardised to use a new pw_check (overridable in the config) parameter, which defaults to:
>
>     drupal_password_check($passwordhash,$password)
>
>
> and stopped using the pw_encode config value. I also changed the MQ authentication stuff to use the same pw_check parameter (so both authentication uses are
> now able to be changed in the same config). If using something other than drupal, just need to change the pw_check parameter in the config.
>
> I realise that this may break other users of the server, but it doesn’t seem a difficult fix to make, and is a much better approach.
>
> Regards, Mark
>
>> On 19 Feb 2020, at 1:53 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>
>> Strange. I have zero using mine. Must be a EU thing?
>>
>> I’ll keep it in mind and try not to break anything.
>>
>> Regards, Mark.
>>
>>> On 18 Feb 2020, at 8:41 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>
>>> Mark,
>>>
>>> grep "main: http" in the log: yes, I've got some users accessing the API frequently.
>>>
>>> Usage is mostly /api/charge followed by /api/status & /api/historical, but almost all calls have been used during the last days.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 18.02.20 um 04:28 schrieb Mark Webb-Johnson:
>>>> Is anyone here using the HTTP API at all?
>>>>
>>>> It seems so tied to the v2 protocol, as to not be much use.
>>>>
>>>> Regards, Mark.
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> -- 
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200220/17c8bfef/attachment.htm>