Best practice for using Fabric/Crashlytics with open-source app?
Best practice for using Fabric/Crashlytics with open-source app?
I have an iOS app that I'm about to open source. I don't want to include my key and secret in the Run Script code when the the app is live for everyone to look at, fork, download etc. for obvious reasons.
What is the best way to still use Fabric/Crashlytics but also keep those keys secure so that only those who can deploy the app have access to those credentials?
Only sort of helpful. Android-related post...
– Zack Shapiro
Jan 28 at 21:07
3 Answers
3
Here's a way:
1 - Store fabric keys in a local file.
<apiKey>
<secretKey>
2 - In your cocoa pods run script phase (under Build Phases in Xcode), have your script grab the api key and secret key from the local file.
apiKey=$(sed -n '1p' < localFile.txt)
secretKey=$(sed -n '2p' < localFile.txt)
3 - Use PlistBuddy
in the cocoa pods run script phase to set the API Key into your Info.plist
file. Something like this:
PlistBuddy
Info.plist
/usr/libexec/PlistBuddy -c "Set :Fabric:APIKey string $apiKey" $(PROJECT_DIR)/Info.plist
4 - Call the cocoa pods run
command.
run
"$PODS_ROOT/Fabric/run" $apiKey $secretKey
Edit: full script
apiKey=$(sed -n '1p' < localFile.txt)
secretKey=$(sed -n '2p' < localFile.txt)
/usr/libexec/PlistBuddy -c "Set :Fabric:APIKey string $apiKey" $(PROJECT_DIR)/Info.plist
"$PODS_ROOT/Fabric/run" $apiKey $secretKey
Is this all in one Run Script?
– Zack Shapiro
Jan 29 at 20:07
Yes. There should already be a run script with the cocoa pods
run
command. Edit that run script with the code above (may need some slight tweaking).– Jake
Jan 29 at 20:13
run
Thanks, working on that now. Seeing what needs tweaking
– Zack Shapiro
Jan 29 at 20:16
Made a small edit, thanks for your help, Jake
– Zack Shapiro
Jan 29 at 21:17
This didn't work for me and the issue originates from the path to
Info.plist
, I found a solution and posted another answer.– Vahid Amiri
Jul 11 at 3:15
Info.plist
Jake's answer didn't work for me. Apparently $(PROJECT_DIR)/Info.plist
returns an incorrect path.
$(PROJECT_DIR)/Info.plist
But here's a working example for a project that uses both Fabric and Google sign in. (This works perfectly in Xcode 9 as of July 2018)
FabricApiKey=$(sed -n '2p' < app_config.txt)
FabricSecretKey=$(sed -n '4p' < app_config.txt)
GoogleReversedClientId=$(sed -n '6p' < app_config.txt)
INFO_PLIST="$BUILT_PRODUCTS_DIR/$INFOPLIST_PATH"
/usr/libexec/PlistBuddy -c "Set :Fabric:APIKey $FabricApiKey" "$INFO_PLIST"
/usr/libexec/PlistBuddy -c "Set :CFBundleURLTypes:0:CFBundleURLSchemes:0 $GoogleReversedClientId" "$INFO_PLIST"
"$PODS_ROOT/Fabric/run" $FabricApiKey $FabricSecretKey
and here's the structure of app_config.txt
file that must be present at the project root:
app_config.txt
FabricApiKey:
your_key_here
FabricSecretKey:
your_secret_here
GoogleReversedClientId:
google_reversed_client_id_here
Excellent post by @Jake - thank-you! This is my variation which checks for the existence of the secrets file, and uses some environment variables provided by Xcode 9.4.
#1/usr/bin/env sh
secretsFile=$PROJECT_DIR/scripts/fabric.secrets
if [ ! -f $secretsFile ]; then
echo "warning: '$secretsFile' not found"
exit 0
fi
apiKey=$(sed -n '1p' < $secretsFile)
secretKey=$(sed -n '2p' < $secretsFile)
/usr/libexec/PlistBuddy -c "Set :Fabric:APIKey $apiKey" $PRODUCT_SETTINGS_PATH
$PROJECT_DIR/Fabric.framework/run $apiKey $secretKey
Note: the echo "warning: "
part will be detected by Xcode, and put into the build log as a yellow warning.
echo "warning: "
Finally, here's a pre-commit git hook to check for a 40-character hex string accidentally being added to the Info.plist
:
Info.plist
#!/usr/bin/env sh
files=$(ls */Info.plist)
git diff --cached --name-status | while read modificationtype thisfile; do
if [ "$modificationtype" == 'D' ]; then continue; fi
for file in $files
do
if [ ! "$thisfile" == "$file" ]; then continue; fi
if egrep '[0-9a-fA-F]40' $file ; then
echo "ERROR: API key in file: $file"
exit 1
fi
done
done || exit $?
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
What about: stackoverflow.com/questions/47880326/…
– Marek van der Hoeven
Jan 28 at 18:08