opensource
opensource copied to clipboard
sendgrid
SendGrid Android Library
I found this Android Library on the SendGrid website and I've noticed it hasn't received any update in years.
I would like to start (from scratch) a new Android Library for SendGrid, but this time written in Kotlin to keep code more clean and concise. It should be interoperable with Java so that Android Developers who haven't adopted Kotlin yet can also use it.
Let me know what you think
@rosariopfernandes This sounds great. One design question is how you would anticipate securing the API key?
@aroach TBH I had not considered that when I thought of this. But there are 3 options I can see right now:
1. Store it in BuildConfig
We could store the API key on the global gradle.properties file (~/.gradle/gradle.properties). This makes it accessible in the source code from he BuildConfig class, as shown in this post.
Downside: According to some comments on this post, this method is not secure at all since the API key will be bundled into the APK, which can be reverse engineered afterwards. They recommend using the NDK method instead.
2. NDK
It's possible to store the key in a C/C++ class and access it from the Java class.
Downside: this blog post mentions the existence of tools like Hex-Rays that can reverse engineer those classes and find the key.
3. Integrate the library with Firebase
(the most complicated of all) Firebase is being widely used for mobile app development nowadays. I suggest having a Cloud Function making requests to the SendGrid API. And the mobile library should only make requests to that cloud function. Since the function is executed on the server-side, the API key is not exposed.
Downsides:
- Developers would need to integrate Firebase in their apps with billing enabled in order to use the SendGrid android library.
- Developers would probably need to setup user authentication using Firebase Auth, to make sure the Cloud Function is not called by unregistered people/bots.
Feel free to add any other possible option(s) here.
There's no perfect solution to storage of an API key. A determined person with the right amount of skills would probably get the key no matter which is used above. The only method I think is appropriate is if there is some kind of user input at run time but then again, a typical user should not have to deal with api keys. Boy, this is such a conundrum! :grin:
