Closed w0 closed 10 months ago
So... This make sense. I probably should not have made these so generic. I also thought Graham was keeping the "tradition" of JSSImporter by prefixing the expect override variables with JSS_
.
Either way, the override variables in my CrowdStrike Recipes should probably be changed to not be generic as not to conflict with other things that may pop up in the future.
Give me a bit and I'll see what I can get done. I actually had someone else DM me yesterday about these recipes and led to so possible documentation improvements at the very least.
I probably should change the keys in JamfUploader too before many people use them. I'll get on it.
Best wishes, Graham On 3 Nov 2023 at 21:16 +0100, Zack T @.***>, wrote:
So... This make sense. I probably should not have made these so generic. I also thought Graham was keeping the "tradition" of JSSImporter by prefixing the expect override variables with JAMF_. Either way, the override variables in my CrowdStrike Recipes should probably be changed to not be generic as not to conflict with other things that may pop up in the future. Give me a bit and I'll see what I can get done. I actually had someone else DM me yesterday about these recipes and led to so possible documentation improvements at the very least. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Resolved with #70.
When using JamfUploader processors with CrowdStrikeURLProvider, both recipes share the same key names client_id and client_secret. JamfUploader tries using those client_id and client_secret variables during authentication workflows.
I was trying to come up with a method to work around this. But nothing comes to mind that isn't a breaking change for one of the processors. Maybe using more unique key names would help mitigate this.
ex: crowdstrike_id or jamf_id
@grahampugh