- introduced recently in these log format changes.
- require_once 'ykval-config.php in logformat()
did not import, because it takes place in ykval-verify.php.
- hence logformat() did not have $baseParams in scope,
so we never write the log line.
- refactor and set format outside the class itself.
- Traditionally we wrote two lines for each ykval-verify.php call,
'Request:' and 'Response:'.
- This commit allows us to log both request/response values in a single line.
- For backward compatibility, the old logging is kept in place.
- To write this line to syslog, __YKVAL_VERIFY_LOGFORMAT__ needs to be set.
- simplify and avoid using different arrays with same values.
- build $otpParams from $otpinfo as soon as we have ksm result,
then unset $otpinfo.
- futher down, only use $otpParams and $localParams.
- avoid doing what is already handled by the Log class.
- the log name is appended automatically,
so don't append it again in the invocation.
i.e. "ykval-verify"
- the log level name is also appended automatically,
so don't append it manually, especially when it doesn't match the log priority!
i.e. LOG_WARNING -> ":notice:"
- fix whitespace in some messages.
- strftime -> date.
- strftime is same as date, but with locales.
- date format doesn't output names (January, March, etc.),
so locale doesn't matter.
- also, would we really want locale in logs?
- Log::log() internally support array implode,
so no need to duplicate functionality.
- however, the internal implode uses two consecutive spaces as separator,
so this will change the log format slightly.
e.g. "delta=x now=y" becomes "delta=x now=y"
- same as 1e799aa6e5.
- group $timeout filtering and validation.
- this commit might change replies sent to clients,
since the validation check is done eaerlier now,
and we might return S_MISSING_PARAM before S_BAD_OTP for example.
- this should really not cause any issues though,
the order of which error is raised first should not matter to clients.
- group $sl filtering and validation.
- this commit might change replies sent to clients,
since the validation check is done eaerlier now,
and we might return S_MISSING_PARAM before S_BAD_OTP for example.
- this should really not cause any issues though,
the order of which error is raised first should not matter to clients.
