Added a call to stripslashes for the 'apikey_name' field to ensure it is unescaped before being returned. This improves display consistency for API key names containing escaped characters.
Simplifies the API key validation in auth_key_login by removing the requirement for connection_by_header. Now, API keys matching the pattern are accepted regardless of the connection source.
* Introduces a verification code step before generating password reset links.
* New configuration "password_reset_code_duration".
* Adds Base32, TOTP and PHPQRCode classes .
* New section is required in password.tpl: code verification won't work on themes not updated yet.
* 5 new language strings were added.
Adds logic to detect when an API key is about to expire and sends a notification email to the user if the key expires within 7 days and no recent notification was sent. Introduces a new 'last_notified_on' column to the user_auth_keys table to track notification timing.
...and improve profile JS. Replaces can_manage_api_key() with connected_with_pwg_ui() to ensure API key management is only allowed from UI logins, and sets 'connected_with' in session during auto-login. Refactors profile.js to respect canUpdatePreferences and canUpdatePassword, moves user state initialization to template, and improves preference reset/default logic. Also adjusts script loading and minor UI details in profile.tpl.
- Added API key get, creation, editing, and revocation methods.
- Updated the profile template to include API key management features.
- Updated the database schema to support the new API key system, including additional fields for key management.
- Added client-side JavaScript functionality to handle API key operations and display responses.
- Update tools/htm.ws with the new way to authenticate.
- Restriction of certain api methods when used with an api key
- Backward compatibility with older apps
create new theme standard pages with tpl, css, js and images
update backend to handle pages
add config use_standard_pages
on update set config to false, on install set config to true
add standard pages to no be ingored in git
When a password activation or reset link is generated, the link expiry time is now defined in two conf: $conf[’password_reset_duration‘] with a default time of one hour and $conf[’password_activation_duration‘] with a default time of 72 hours.
- add field for add user
- in the `pwg.users.add` method, the params `send_password_by_mail` does nothing anymore. Because we no longer want to send passwords in clear text.
- in the `pwg.users.add` add a new `auto_password` parameter to generate a random password when a user is created
- use this parameter (`auto_password`) in user_list.js
- change mail content et password page on first login
- Implementation of a new modal for modifying a user or guest
- Addition of a function to allow plugins to add a tab to the new user modal
- Fix bug: "badger-number" is updated when a user is added or deleted
- Fix bug: When the user who is editing has permissions to delete the user he is modifying, the delete icon is now displayed correctly
- Added a new api method for modifying the main user and generating a link to reset a password
- Passed $conf[‘webmaster_id’] in database configuration
In PHP 7.2 and later you will get a warning if you call count() on null. So either initialize $errors to an empty array here, or use empty() to check it as I have done here.
When loading a user's theme, make sure it's installed. Also, when
determining the default theme, account for the situation in which
zero themes are installed (and use 'default' then).
Refs #1061
This will speed up user edit popin opening, by avoiding to search in history for the last user visit.
The column user_infos.last_visit_from_history true/false says if the last_visit has already been search in history (to avoid making it twice). I could have implemented the search of last_visit for all users in the migration task 149 but in case of many users and long history, it would have taken years to execute...
When a user successfully performs an authentication with an auth_key, Piwigo
registers it in the history table.
For now, it is not shown/searchable in the history screen, but we can add it
in the future and we can provide a plugin with specific details about
authentication keys usage.
