fusiondirectory issueshttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues2023-01-30T10:14:36Zhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6252add attribute values in the audit logs2023-01-30T10:14:36Zbmortieradd attribute values in the audit logs### Requirements
it requires new config attributes in fusion directory schema
## Descriptive title for this enhancement
When making an action on any entry, the values are not logged in the audit logs.
It could be interesting to have ...### Requirements
it requires new config attributes in fusion directory schema
## Descriptive title for this enhancement
When making an action on any entry, the values are not logged in the audit logs.
It could be interesting to have the details of the action. For example:
```
Object Values: add:description=foo
Object Values: replace:cn=bar
Object Values: delete:l
```
### Current behavior
No value logged in the audit logs
### Expected behavior
Values logged in the audit logs, in case of `changetype: add` or `changetype: modify`
For `changetype: modify`, we should also log if the attribute has been deleted / replaced / added.
### Benefits
Better audit logging
### Possible Drawbacks
Consume much more data in LDAP. Maybe we should have an option to enable / disable value logging.FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6251audit the lock / unlock actions2023-01-31T17:46:30Zbmortieraudit the lock / unlock actions
## Descriptive title for this enhancement
Currently, it seems there is no audit log for "lock / unlock" actions. (even in security action types)
It would be nice to have these logs, maybe as a "security" action type.
### Actual behavi...
## Descriptive title for this enhancement
Currently, it seems there is no audit log for "lock / unlock" actions. (even in security action types)
It would be nice to have these logs, maybe as a "security" action type.
### Actual behavior
Nothing appears in the audit logs
### Expected behavior
A new log entry for each lock/unlock action
### Benefits
* more audit logs
### Possible Drawbacks
* /FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6242[PHP_FATAL_ERROR] - Management of error display in case of PHP_FATAL_ERROR - ...2023-02-02T11:37:06Zbmortier[PHP_FATAL_ERROR] - Management of error display in case of PHP_FATAL_ERROR - Automated CI and tests verification may produce that type of error.### Requirements
In case a PHP_ERROR_FATAL would be triggered, it would be important to have a clear message if DEBUG is on within FD.
## Descriptive title for this enhancement
<!-- required -->
### Actual behavior
As example, durin...### Requirements
In case a PHP_ERROR_FATAL would be triggered, it would be important to have a clear message if DEBUG is on within FD.
## Descriptive title for this enhancement
<!-- required -->
### Actual behavior
As example, during the automated testing triggered by a merge request or packaging deployment, PHP_ERROR_FATAL may occur and result in a total failure of running tests. Without knowing the real reasons of the error, it is hard to debug properly.
### Expected behavior
A proper error message with the root cause of the problem is mandatory.
### Step by step description of new behavior
In order to reproduce a PHP_FATAL_ERROR, first the variables within variables.inc in /include must be ON. (Is Always ON during tests executions with CI).
For example, if a path to an ICON image cannot be found, a PHP_ERROR_FATAL will be thrown. Resulting in the deletion of the PHP session.
The error message should be triggered before the deletion of the session and the automated reload page (message would disapear).
### Benefits
Debugging time will be shorter as error message is reporting line and proper error message.
### Possible Drawbacks
None
### Applicable Issues
<!-- optional -->
<!-- Enter any applicable Issues here -->FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6232Password recovery allows spurious additional emails2023-04-25T13:16:53ZbmortierPassword recovery allows spurious additional emails### Description
The password reset/recovery functions allow spurious, additional email addresses to be used beyond the email address or personal address for the outbound recovery email.
It is unclear where exactly this is occurring, bu...### Description
The password reset/recovery functions allow spurious, additional email addresses to be used beyond the email address or personal address for the outbound recovery email.
It is unclear where exactly this is occurring, but the behavior is obviously insecure and undesirable.
### Distribution Name and Version
Debian 10.13
### FusionDirectory Version
FusionDirectory 1.3.1
### PHP version used
PHP 7.3
### Origin of php packages
Debian distribution packages
### Steps to Reproduce
1. Bad actor inputs spurious additional input beyond a known-good email address on the recovery.php page
2. Password reset email is sent to the known-good email address as well as the bad actor
**Expected behavior:**
Input should be rejected or only the known-good matching email address should be used.
**Actual behavior:**
An email is sent to two locations - both directly to the user (as expected) and to the bad actor. This is send as a single email with two recipients.
**Reproduces how often:**
It is unclear how reproduceable this issue is. Inserting a basic comma does not pass the filtering requirement on the recovery form. However, we can confirm (from email logs and from the user themselves) that a recovery email was generated with two recipients.
### Additional Information
The URL generated might be helpful for tracking this down:
https://[Our FD installation]/recovery.php?uniq=[uniqueString]&login=[user]&email_address=[user]%40[our site]%00%2Ccirah11891%40botsoko.com
The "cirah11891%40botsoko.com" is the bad actor's email address (so I have no issues sharing it), although it's unclear how this a) passed validation checks or b) generated the 2nd recipient on the email.
After this incident, I have added some additional code to strip out any comma-separated email addresses and only use the first value (this is within the step2() function in class_passwordRecovery.inc), but even without that additional code, I was unable to replicate the issue directly.
My speculation is that something about the user-submitted string causes it to be ignored by the ldap filter, but the definition of $this->email_address = $_POST['email_address']; (line 314 in FD version 1.3.1) is never sanitized, allowing additional email address(es) to leak in to the process.FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6194Make an unicity backend in FusionDirectory configuration2023-06-25T21:02:07ZbmortierMake an unicity backend in FusionDirectory configuration## Descriptive title for this enhancement
Currently, all the unicity logic is in the code. It will be nice to be able to change it per attribute in the FusionDirectory configuration.
### Actual behavior
Only in the code
### Expected ...## Descriptive title for this enhancement
Currently, all the unicity logic is in the code. It will be nice to be able to change it per attribute in the FusionDirectory configuration.
### Actual behavior
Only in the code
### Expected behavior
Possibility to change and adapt from UI
### Step by step description of new behaviour
1. Go to configuration
2. Use default or customize the unicity settings
3. Save
### Benefits
Having everything in LDAP and an easy way to change them
### Possible Drawbacks
It will need a change on any part that concern the unicity (core, plugins).
It must be taken into account that someone can break the configuration. It will need a way to reset with default settings too.
### Applicable Issues
NoneFusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6175Compatibility with PHP 8.12022-10-17T13:32:08ZbmortierCompatibility with PHP 8.1The main change we need to do is to avoid using is_resource function to check for success, because most resources are replaced by objects, and in 8.1 this will be the case for ldap links and results.The main change we need to do is to avoid using is_resource function to check for success, because most resources are replaced by objects, and in 8.1 this will be the case for ldap links and results.FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6140Refactore saving and triggers workflow2022-02-21T21:32:48ZbmortierRefactore saving and triggers workflowSplit from #6063
Present situation:
```mermaid
sequenceDiagram
loop each tab
simpleTabs->>+simplePlugin:Check
simplePlugin-->>hooks:Check hook
simplePlugin-->>-simpleTabs:.
end
simpleTabs->>LDAP:Move (if dn changed)
loop each ta...Split from #6063
Present situation:
```mermaid
sequenceDiagram
loop each tab
simpleTabs->>+simplePlugin:Check
simplePlugin-->>hooks:Check hook
simplePlugin-->>-simpleTabs:.
end
simpleTabs->>LDAP:Move (if dn changed)
loop each tab
simpleTabs->>+simplePlugin:Save
simplePlugin-->>hooks:Pre hook
simplePlugin->>LDAP:save
simplePlugin-->>simplePlugin:Forein key handling
simplePlugin-->>hooks:Post hook
simplePlugin-->>-simpleTabs:.
end
```
Notes
1. An error in pre hook or tab save cancels a tab saving (only this tab)
1. An error in main object creation cancels whole creation (obviously)
1. When hooks are running, partial data is in the LDAP
2. When errors are met upon creation in a tab, object is partially created
We should change to something that runs all pre-save computing, then runs a single LDAP operation, the runs post-save computing.
But, we need to keep in mind that this is only the simple case, and some plugins do lots of other things in their save method. They may modify other objects or subnodes, some will call APIs to update other systems. All of which would become part of post-save computing, and run only if LDAP modification passed.
If we go this road, we might also want to look into making both previous and future values of attributes to hooks as this is a current limitation.
The new workflow should be:
```mermaid
sequenceDiagram
loop each tab
simpleTabs->>+simplePlugin:Check
simplePlugin-->>simplePlugin:Check attribute values
simplePlugin-->>hooks:Check hook
simplePlugin-->>-simpleTabs:.
end
loop each tab
simpleTabs->>+simplePlugin:PrepareSave
simplePlugin-->>simplePlugin:Fill LDAP operation
simplePlugin-->>hooks:Pre hook
simplePlugin-->>-simpleTabs:.
end
simpleTabs->>LDAP:Move (if dn changed)
simpleTabs->>LDAP:Save (ldap_modify_batch)
loop each tab
simpleTabs->>+simplePlugin:PostSave
simplePlugin-->>simplePlugin:Non-LDAP save
simplePlugin-->>simplePlugin:Forein key handling
simplePlugin-->>hooks:Post hook
simplePlugin-->>-simpleTabs:.
end
```
- Is it necessary to split move and save?
- Should the Save LDAP call go through simplePlugin main tab?
- Hooks should only be called if the tab changed (except check hooks).
- We may want special posthook that are called after complete saving, and lock release
- We may want normal posthook to happen in a separate loop after non-ldap save anyway
- We need to design how LDAP save in other objects happens. For instance when modifying a sub object, or when modifying another object (DNS configuration from system edition for instance)
- How can we give hooks access to before/after values of attributes?
- How can we easily allow hooks to alter attributes?
- How can we give hooks API tokens?
The hooks questions seems to be pointing to allow hooks to edit the LDAP modification array, but that means forcing them to use LDAP syntax for attributes. In which case maybe the best would be to use LDIF format as in/out of hooks.FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6091Object deletion should not delete each tab separately2022-02-21T21:17:34ZbmortierObject deletion should not delete each tab separatelyAn object deletion should result in only one LDAP deletion, not removal of each tab and then deletion on the node like currently.
This may make some trigger configuration harder, but it will be a lot better performance wise and avoid we...An object deletion should result in only one LDAP deletion, not removal of each tab and then deletion on the node like currently.
This may make some trigger configuration harder, but it will be a lot better performance wise and avoid weird LDAP errors.
Can be built on top of #5747FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6063Partial entry created when error occurs in a tab2022-09-30T18:41:40ZbmortierPartial entry created when error occurs in a tab### Description
I created an entry and enabled the mail tab in the creation screen. My LDAP directory is configured with unique overlay on mail attribute. If the mail of the created entry is not unique, I got an error, but the entry is ...### Description
I created an entry and enabled the mail tab in the creation screen. My LDAP directory is configured with unique overlay on mail attribute. If the mail of the created entry is not unique, I got an error, but the entry is created without the mail tab.
### Distribution Name and Version
Debian stable
### FusionDirectory Version
1.4-2~jenkinsbuild570
### Steps to Reproduce
1. Create a new entry, enter required information
2. Enable mail tab, set a mail address which already exists
3. Enter OK
**Expected behavior:**
Error message because LDAP Directory has reject the mail attribute, and no entry created at all.
**Actual behavior:**
Error message because LDAP Directory has reject the mail attribute, but entry is created without the mail attribute.
**Reproduces how often:**
100%
### Additional Information
Configuration of OpenLDAP unique overlay:
```
dn: olcOverlay={2}unique,olcDatabase={1}mdb,cn=config
objectClass: olcUniqueConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {2}unique
olcUniqueURI: ldap:///?mail?sub
```FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6048Switch to PSR-4 autoloader2022-02-21T21:44:22ZbmortierSwitch to PSR-4 autoloaderFusionDirectory currently use an old-school autoloader, which relies on «fusiondirectory --update-cache» being run.
Modern PHP (especially stuff using Composer) tend to use autoloaders following this norm: https://www.php-fig.org/psr/ps...FusionDirectory currently use an old-school autoloader, which relies on «fusiondirectory --update-cache» being run.
Modern PHP (especially stuff using Composer) tend to use autoloaders following this norm: https://www.php-fig.org/psr/psr-4/
### Actual behavior
<!-- What actually happens -->
`fusiondirectory --update-cache` parse all our PHP files and stores the class paths in a cache file.
We register `__fusiondirectory_autoload` as an autoloader, which uses this cache file to find the classes.
We had to add an exception for smarty classes as smarty has its own autoloader.
### Expected behavior
<!-- What you expect to happen-->
Use a PSR-4 autoloader in a autoload.php file.
### Step by step description of new behaviour
<!-- Required -->
This would require a huge reorganization of the code:
1. Use namespaces
2. Use subnamespaces for directories
3. One file for each class, ending in .php (no more .inc)
### Benefits
<!-- optional -->
<!-- What benefits will be realized by the code change? -->
1. No more need for `--update-cache`
2. Interoperable with other autoloaders
3. Makes it possible to use tools like phpstan, or libraries based on composer (most of them are nowadays)
### Possible Drawbacks
<!-- optional -->
<!-- What are the possible side-effects or negative impacts of the code change? -->
1. Heavy use of namespaces
2. Break of any code relying on current FD organization
3. Redo packaging
4. Rewrite stuff like `--install-plugins`
### Applicable Issues
<!-- optional -->
<!-- Enter any applicable Issues here -->FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6022use reuse from fsfe for licence compliance2022-02-21T21:36:38Zbmortieruse reuse from fsfe for licence compliance## Descriptive title for this enhancement
use reuse from fsfe for license compliance https://reuse.software/
### Actual behavior
license compliance is done manually who is tedious and error prone
### Expected behavior
be able to ch...## Descriptive title for this enhancement
use reuse from fsfe for license compliance https://reuse.software/
### Actual behavior
license compliance is done manually who is tedious and error prone
### Expected behavior
be able to check compliance with reuse tool and integrate into the gitlab ci
### Step by step description of new behaviour
<!-- Required -->
1. follow https://reuse.software/faq/
### Benefits
* no more management by hand
* discover license non compliance automatically
### Possible Drawbacks
conversion time
### Applicable Issues
licenseFusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/5619Template creation workflow is a bit weird2022-02-21T21:43:18ZbmortierTemplate creation workflow is a bit weirdWhen creating a template an object is created and then turned into a template with setTemplate/setTemplateMode.
It would be better if the constructors knew right away the object is a template.When creating a template an object is created and then turned into a template with setTemplate/setTemplateMode.
It would be better if the constructors knew right away the object is a template.FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/5530It would be useful for plugins to be able to declare triggers2022-09-30T18:43:26ZbmortierIt would be useful for plugins to be able to declare triggersA plugin should be able to ask to be called in any standard triggers event (pre-modify on users for instance).A plugin should be able to ask to be called in any standard triggers event (pre-modify on users for instance).FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/4601simplePlugin should handle the case where several LDAP attribute are displaye...2022-09-30T18:43:13ZbmortiersimplePlugin should handle the case where several LDAP attribute are displayed as oneThe opposite is well handled with CompositeAttribute.
But when several LDAP attributes are handled by one simplePlugin attribute, as for DNS records, it gets complicated.
The way ->attributes is handled could be updated to take this int...The opposite is well handled with CompositeAttribute.
But when several LDAP attributes are handled by one simplePlugin attribute, as for DNS records, it gets complicated.
The way ->attributes is handled could be updated to take this into account.FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/3374Password change should be done using the LDAP Password Modify Extended Operation2022-02-21T21:31:23ZbmortierPassword change should be done using the LDAP Password Modify Extended Operationhttps://www.ietf.org/rfc/rfc3062.txt
This might help using ppolicy.
Also, all password change in FD should go through the change_password function as it takes care of things like samba sync or shadowAccount update.https://www.ietf.org/rfc/rfc3062.txt
This might help using ppolicy.
Also, all password change in FD should go through the change_password function as it takes care of things like samba sync or shadowAccount update.FusionDirectory 1.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6319Add a check / warning when adding ssha512 password method that overlay pw-sha...2024-03-28T10:51:25ZJonathan SwaelensAdd a check / warning when adding ssha512 password method that overlay pw-sha2 must be usedAdd a check / warning when adding ssha512 password method that overlay pw-sha2 must be usedAdd a check / warning when adding ssha512 password method that overlay pw-sha2 must be useddockx thibaultdockx thibaulthttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6318The "default policy" is not applied2024-03-24T18:04:51ZJonathan SwaelensThe "default policy" is not appliedHello @tdockx
- Install ppolicy plugin and overlay
- Add a default policy
```
dn: cn=default,ou=ppolicies,dc=example,dc=com
objectClass: device
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
pwdAttribute: userPassword
cn: defaul...Hello @tdockx
- Install ppolicy plugin and overlay
- Add a default policy
```
dn: cn=default,ou=ppolicies,dc=example,dc=com
objectClass: device
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
pwdAttribute: userPassword
cn: default
pwdAllowUserChange: TRUE
pwdSafeModify: FALSE
pwdCheckQuality: 0
pwdLockout: TRUE
pwdInHistory: 2
pwdMustChange: FALSE
```
- Add a user to the ACL editownpassword
- Connect with this user and change your password
- It will not trigger the history error or same password error if you don't assign the policy to the user explicitly
Cheers
![image](/uploads/d10b3a6cebc9b0362ba274c167e70f2c/image.png)
![image](/uploads/d2250270307e95b9ade38548d21d281c/image.png)
![image](/uploads/06a0f87a0439c115d5a3e3560b545f28/image.png)dockx thibaultdockx thibaulthttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6317[core] - new column for primary and secondary supann affiliation2024-03-19T17:23:45Zdockx thibault[core] - new column for primary and secondary supann affiliation[core] - new column for primary and secondary supann affiliation
The idea is that a new column type should be available in case there would be a supann affiliation required to be seen.
Only the code is actually seen, it should be evalua...[core] - new column for primary and secondary supann affiliation
The idea is that a new column type should be available in case there would be a supann affiliation required to be seen.
Only the code is actually seen, it should be evaluated to its related string value.dockx thibaultdockx thibaulthttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6308Having a way to create ordered away with a column as reference2024-02-06T14:34:00ZJonathan SwaelensHaving a way to create ordered away with a column as referenceHello @tdockx
When we add elements, it would be nice to have a way to specify which column must be seen as reference in so that we cannot have multiple entries.
It would be nice to have a concept of one unique key instead of one key w...Hello @tdockx
When we add elements, it would be nice to have a way to specify which column must be seen as reference in so that we cannot have multiple entries.
It would be nice to have a concept of one unique key instead of one key with multiple status. With the latest one overwritting the old one).dockx thibaultdockx thibaulthttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6305[CORE][Task] - type mail should include a BCC field2024-02-05T16:36:55Zdockx thibault[CORE][Task] - type mail should include a BCC field[CORE][Task]- type mail should include a BCC field
Orchestrator has already the capabilities to integrate BCC but the arrays of attributes returned do not receives replyTo or BCC values yet.[CORE][Task]- type mail should include a BCC field
Orchestrator has already the capabilities to integrate BCC but the arrays of attributes returned do not receives replyTo or BCC values yet.dockx thibaultdockx thibault