Mark, I haven't understood completely yet why there could be confusion on the command parameters. For example, "PASS" now is in mode 2. If it's called as "PASS <newpw>", net_sms_checkpassarg() would not touch the args. If it's called "PASS <oldpw> <newpw>", net_sms_checkpassarg() will authorize the call and remove <newpw> from the args -- for the PASS handler, everything looks the same. "PASS <oldpw>" would result in clearing the module password, but a check for a non empty <newpw> makes sense there anyway. Is there a case where the first argument could be identical to the module password? And couldn't we just tell the users they need to choose a secure password (i.e. not one identical to the module or server name)? I also think it's important for us to remember considering all commands in auth modes "2" and "3" as insecure, as they can be called from anyone just by faking the caller id. I guess that's not a real problem yet, but it could become one. For example, my DEBUG command now outputs the current GPS position, so someone trying to spy me out could easily track me using that output. ...*lol*, there're already even web services available for caller id faking: http://calleridfaker.com/ => It would be nice for a handler to know the auth level of the call. So my DEBUG handler could output GPS position only if it's been called with the module password. This could be done by changing the net_sms_checkauth() result to a char reflecting the auth level reached, i.e. 0=auth failure, 1=caller id, 2=password, and passing that through to the handlers. Regards, Michael Am 18.11.2012 09:21, schrieb Mark Webb-Johnson:
The auth modes directly map to the three ways of doing it in the old code. Just standardised them and implemented in one place to save space, and reduce the amount of work needed to be done in the handlers.
Some commands can ONLY work with a password (things like REGISTER used to change the registered phone - which can obviously not work with a caller id).
Some commands can work with EITHER a password OR a registered phone (things like STAT).
Other commands can ONLY work with a registered phone (normally commands used to set settings like SERVER, MODULE, etc - where the presence of a password could be confused with the parameter itself).
Regards, Mark
On 18 Nov, 2012, at 6:08 AM, Michael Balzer <dexter@expeedo.de> wrote:
Am 17.11.2012 19:20, schrieb Michael Balzer:
Thinking about auth... maybe I'm missing something, but why is there a need for the three auth modes? Couldn't it just be mode 3 for every command? Ok, thinking about it a bit more (I'm getting old...), a caller id obviously can be faked, so mode 1 definitely makes sense.
But it still looks like mode 2 is included in mode 3...?
Michael
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26