monitors/alarm/command:on now takes an optional cause (query or POST data)
and passes it to zmu --cause, so the event records it in place of
"Forced Web". Without a cause nothing changes.
The cause is stored as the event's Cause and in its Notes, so alarmCause()
keeps it to plain text: letters, digits, spaces and plain punctuation, cut
to the 31 bytes zmu stores on a character boundary, falling back to the
default when nothing is left. The value is quoted with escapeshellarg()
for the zmu command line.
Test: tests/php/test_monitor_alarm_cause.php
fixes#5348
db/zm_create.sql seeds the admin account with the password the user
guide documents (admin), so with authentication on a new install is
still open to anyone who reads the guide.
Refuse that password as a credential and have the web login replace it:
- validateUser() returns false with "This account uses the password
admin, which ZoneMinder does not accept. Log in to the web interface
to set a new one." when the password is right but is admin. The API (login.json and
user=/pass= on any request) answers 401 with that message; the
user=/pass= web parameters are refused the same way.
- On the login page (action=login) the same login shows a form that
asks for the current password again and a new one, with a nonce kept
in the session so another site can't submit it for the user. The new
password must be set, confirmed and not the default. The account is
logged in only once it has been replaced; the change is audited.
That POST skips reCAPTCHA when it carries the form's nonce: the form
follows a login that passed it, and doesn't render the widget.
With ZM_AUTH_RELAY=plain the session keeps the new password.
- zmLoadUser() refuses the default password, so zms, zmu and the RTSP
server don't accept it in user/password parameters either.
The check is on the password typed, so it needs no schema change, covers
existing installs whose admin still has the default password, and
follows the account if it is renamed. A password set to the default
again later is caught the same way. Sessions, tokens and auth hashes
issued before the upgrade keep working until they expire; with
ZM_AUTH_TYPE=remote the web server's login is not affected.
The FAQ now says to force authentication on in conf.d: since 4d7609d36
the daemons apply zm.conf and conf.d values over the database too.
Tests: tests/php/test_default_password.php (the helpers, and that the
seeded hash is the documented default), tests/zm_user_default_password.cpp.
* If token is present do token based auth and do not do anything with session
* update HostController. Use config constants, don't use sessions
* Remove Session from the components list
* spacing
* Remove Session from App Components list.
* Move APIEnabled check to the api from auth.php
* Rework auth. login using username and password only occurs on login action now. Including auth.php should not touch the session. auth_hash logins no longer touch the session. replace userLogin with a function called validateUser which matches the semantics of validateToken.
* remove debugging
* Add session storage if stateful query param is on, but only for LEGACY_API_AUTH
* fix mUser to username, etc.
* shuffle lines
* use instead of session when generating auth hash.
* Add docs regarding the use of cookies and stateful query param
* Only open/close session if we are clearing a session var
* Use zm_session_start instead of session_start
* Should use zm_session_start instead of session_start
* document that zm_session_start should be called previously to session_regenerate_id
* Don't actually write out the session when generating auth hashes. Means they should never actually persist.
* More backticking of SQL
* add .. to fix#2686
* Use material icons for sort because they look nicer
* fix typo
* have to add authhash to session on login
* restore username&password login for all urls
* fix
* fixes
Nic Boet