To better structure and evolve the authentication system in Piwigo, here is a breakdown of the current and future authentication workflows. This summary aims to guide implementation decisions and ensure compatibility across various clients (web, legacy, modern CLI/mobile).
1. Classic Authentication (session via cookies, current workflow)
Usage: Piwigo web interface or API calls with login/password
POST /ws.php?method=pwg.session.login
Data: username, password
Creates a PHP session
Returns a PHPSESSID cookie
Following requests must include this cookie
Limitations:
Depends on a browser or client that handles cookies
Doesn’t work if 2FA is enabled and not supported by the client
2. Alternative Authentication via API Key (keyID + keySecret as login/pass)
Usage: For compatibility with legacy clients (e.g. Piwigo Lightroom plugin, etc.)
Advantage: Zero client modification, bypasses 2FA
But: Not secure if poorly handled on the server side — the server must differentiate between a real login/password and a key_id/key_secret pair.
Unlike a password, the key_secret is randomly and uniquely generated by Piwigo. Therefore, it is much more secure than a traditional password and can safely bypass 2FA.
3. Modern Authentication via Authorization: <key_id:key_secret>
Usage: Modern clients, mobile apps, CLI tools
The app calls:
GET /ws.php?method=some.method
Authorization: <key_id:key_secret>
A hook or middleware detects this header and checks the key in the database
A pwg_token is automatically added to prevent CSRF
If valid:
The key is associated with a user_id
A temporary session is created for the duration of the request, similar to uploadAsync when providing a username and password
To better structure and evolve the authentication system in Piwigo, here is a breakdown of the current and future authentication workflows. This summary aims to guide implementation decisions and ensure compatibility across various clients (web, legacy, modern CLI/mobile).
_________________________________________________________________________________________________
### 1. Classic Authentication (session via cookies, current workflow)
Usage: Piwigo web interface or API calls with login/password
- POST /ws.php?method=pwg.session.login
- Data: username, password
- Creates a PHP session
- Returns a PHPSESSID cookie
- Following requests must include this cookie
Limitations:
- Depends on a browser or client that handles cookies
- Doesn’t work if 2FA is enabled and not supported by the client
_________________________________________________________________________________________________
### 2. Alternative Authentication via API Key (keyID + keySecret as login/pass)
Usage: For compatibility with legacy clients (e.g. Piwigo Lightroom plugin, etc.)
The client uses:
- username = key_id (e.g., `pkid-20250414-qGNVUrtbHIHIVUrttbBoN`)
- password = key_secret (e.g., `dH8HQlo8oQsZcfaKeKEYELRx7EFY01J04RMyb`)
Advantage: Zero client modification, bypasses 2FA
But: Not secure if poorly handled on the server side — the server must differentiate between a real login/password and a key_id/key_secret pair.
Unlike a password, the key_secret is randomly and uniquely generated by Piwigo. Therefore, it is much more secure than a traditional password and can safely bypass 2FA.
_________________________________________________________________________________________________
### **3. Modern Authentication via Authorization: <key_id:key_secret>**
Usage: Modern clients, mobile apps, CLI tools
The app calls:
```
GET /ws.php?method=some.method
Authorization: <key_id:key_secret>
```
- A hook or middleware detects this header and checks the key in the database
- A pwg_token is automatically added to prevent CSRF
If valid:
- The key is associated with a user_id
- A temporary session is created for the duration of the request, similar to uploadAsync when providing a username and password
<!-- github-sync-id:2993567154 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
To better structure and evolve the authentication system in Piwigo, here is a breakdown of the current and future authentication workflows. This summary aims to guide implementation decisions and ensure compatibility across various clients (web, legacy, modern CLI/mobile).
1. Classic Authentication (session via cookies, current workflow)
Usage: Piwigo web interface or API calls with login/password
Limitations:
2. Alternative Authentication via API Key (keyID + keySecret as login/pass)
Usage: For compatibility with legacy clients (e.g. Piwigo Lightroom plugin, etc.)
The client uses:
pkid-20250414-qGNVUrtbHIHIVUrttbBoN)dH8HQlo8oQsZcfaKeKEYELRx7EFY01J04RMyb)Advantage: Zero client modification, bypasses 2FA
But: Not secure if poorly handled on the server side — the server must differentiate between a real login/password and a key_id/key_secret pair.
Unlike a password, the key_secret is randomly and uniquely generated by Piwigo. Therefore, it is much more secure than a traditional password and can safely bypass 2FA.
3. Modern Authentication via Authorization: <key_id:key_secret>
Usage: Modern clients, mobile apps, CLI tools
The app calls:
If valid: