Hi Everyone,
I have searched the forum for a mobile app(android native) and phoenix/elixir backend without luck. can the two mix well, both appear conceptually compelling choices for my project (an eCommerce). i am willing to learn /update. i need direction please.
Best regards
Hi @btajudeen,
Elixir/Phoenix is a good match to an Android client app as any other web framework. Your backend application should expose some sort of API for the mobile app to consume. Most typically, your API would be either a REST/JSON, or GraphQL. Phoenix is a good choice for both (check out Absinth if you decide to go for GraphQL).
That said, it might be difficult to find specific examples of “Android native + Phoenix backend”, simply because there is nothing in the Phoenix backend that is specific to Android apps: the API that an Android app would consume is the same that a web client might consume, so from the Phoenix point of view there is no difference between Android and something else. This is good, because it makes your API reusable: what if you decide to add a iOS app? Or a web client? Having a generic API makes it possible with no change to the backend.
There should be various examples and tutorials on how to implement a JSON API (or GraphQL) with Phoenix, and that will work as an Android app backend as well as for other use cases. Sorry if I am not recommending a specific tutorial, maybe someone has a good one in mind.
Best,
Sir,
Youre awesome for reaching out. This kinda broaden how i should see things. Am delighted and shall read up GraphQL
It seems that you are starting a new project, and as a Developer Advocate for security I would like to recommend that you start your new project with a secure by default approach, and to help with that I recommend that you read this 3 articles I wrote, and take a look to a very basic Andorid mobile app, that shows how to hide an API key in native C code.
While user authentication may let your API server know who is using the API, it cannot guarantee that the requests have originated from what you expect, your mobile app.
Now we need a way to identify what is calling your API server, and here things become more tricky than most developers may think. The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
Now just because the documentation for your API is not public or doesn’t even exist, it is still discoverable by anyone having access to the applications that query your API.
Interested parties just need to set up a proxy between your application and the API to watch for all requests being made and their responses in order to build a profile of your API and understand how it works.
The range of open source tools available for reverse engineering is huge, and we really can’t scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
The best way to hide the API key in an Android mobile app is by using a native C code implementation, as it his done here, and then loaded here, and exposed here, and finally used here.
If you are willing to, then I recommend you the OWASP Mobile Security Project - Top 10 risks:
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
Am thankful for this awesome post. what a sweet introduction to a great community.
© Copyright Elixir Forum | Terms | Privacy & Cookies
