We see that since 1.674 a lot of our actions in DirectAdmin hooks are failing due to lack of information about theuser
andcreator
. This was previously available in many hooks as environment variable.
We use this information to store data and preform (security) checks on external systems which are part of the hosting platform. As some hooks run before theuser.conf
is populated we rely on the information we get from the hooks.
Can this be restored?
This would make the hooks more useful again for all kind of integration cases and checks.![]()
I had a similar issue:
I'm sure this is something specific to just me, because it involves a custom hook. But I suspect that the changes to hook event variables is causing this problem. I'm not sure how to resolve this.
I have a pre_hook - /usr/local/directadmin/scripts/custom/domain_destroy_pre/default_domain.sh - the purpose of which is to prevent end-users from being able to delete their default domain name. (This is so that if they want to delete their default domain, they have...
I have a pre_hook - /usr/local/directadmin/scripts/custom/domain_destroy_pre/default_domain.sh - the purpose of which is to prevent end-users from being able to delete their default domain name. (This is so that if they want to delete their default domain, they have...
- sparek
- Replies: 1
- Forum: General Technical Discussion & Troubleshooting
Was told that "the hooks don't have this variable" despite the information being present prior to 1.674.
I suppose the explanation is "it was never supposed to be there, therefore it was never there."
While I can certainly understand wanting to clean things up and developers perhaps never fully understanding how their misappropriations might be utilized by other users in the wild, but this also underscores having foresight whenever you develop something.
Certainly the DirectAdmin developers never intended for this information to be present in the hooks. But it was. And it was for a long time. Taking that information away is going to affect backwards compatibility moving forward. Ideally, this information leaking out should have been caught a long time ago and fixed and that would have lessened the impact of users in the wild utilizing the information in this leak. But also seeing this from the developer's side, I understand that bugs and unintended consequences aren't always found right away.
This is just an unfortunate event. I'm afraid that the full affects of this fix haven't been felt yet. I'm not sure what the solution is because I can see both sides. Perhaps a better notification of the effects of this change rather than a single sentence in the 1.674 changelog is needed.