elAPI globally follows a "fallback" philosophy where in most cases when it fails, it attempts a pre-defined fallback option. E.g., if an export to a location with --export fails, elPAI will fallback to the location export_dir from elapi.yml. However, this behavior isn't really conventional and can be counter-intuitive if the user is not aware of it. One such case would be: elAPI uses XDG_DOWNLOAD_DIR as one of the fallback locations for exporting with --export. If the user isn't aware of it, and XDG_DOWNLOAD_DIR is set to a location that is publicly accessible, elAPI might expose sensitive information.
We can introduce a --fallback CLI option. When --fallback is passed, and only when --fallback is passed, elAPI attempts a fallback option, unless stated otherwise by a plugin, e.g., bill-teams plugin very much intentionally relies on fallback locations. When --fallback is not passed, elAPI simply quits without attempting any fallback method.
In GitLab by @mhxion on May 4, 2024, 18:33
elAPI globally follows a "fallback" philosophy where in most cases when it fails, it attempts a pre-defined fallback option. E.g., if an export to a location with
--exportfails, elPAI will fallback to the locationexport_dirfromelapi.yml. However, this behavior isn't really conventional and can be counter-intuitive if the user is not aware of it. One such case would be: elAPI usesXDG_DOWNLOAD_DIRas one of the fallback locations for exporting with--export. If the user isn't aware of it, andXDG_DOWNLOAD_DIRis set to a location that is publicly accessible, elAPI might expose sensitive information.We can introduce a
--fallbackCLI option. When--fallbackis passed, and only when--fallbackis passed, elAPI attempts a fallback option, unless stated otherwise by a plugin, e.g.,bill-teamsplugin very much intentionally relies on fallback locations. When--fallbackis not passed, elAPI simply quits without attempting any fallback method.Originally reported by @alexander-haller.