Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--fallback and design decision #32

Open
alexander-haller opened this issue May 4, 2024 · 0 comments
Open

--fallback and design decision #32

alexander-haller opened this issue May 4, 2024 · 0 comments

Comments

@alexander-haller
Copy link
Contributor

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 --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.

Originally reported by @alexander-haller.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant