Chattodo tech stack and security
Tech stack for mobile
1. Java for Android (client side)
2. Firebase Real-time DB: For communication (messaging) and real time data changes.
3. Cloud Functions: For triggers and notifications.
4. Mongo for external server where backup of data stored on firebase is taken. (Currently using an aws server to manage the same)
5. FCM (Firebase Cloud Messaging) : to manage notification updates [push and client to client].
A note on how security is managed in firebase real time environment.
Firebase Realtime Database Rules determine who has read and write access to your database, how your data is structured, and what indexes exist. These rules live on the Firebase servers and are enforced automatically at all times. Every read and write request will only be completed if your rules allow it.
The Firebase Realtime Database provides a full set of tools for managing the security of your app. These tools make it easy to authenticate your users, enforce user permissions, and validate inputs.
Firebase-powered apps run more client-side code than those with many other technology stacks.
The Firebase Realtime Database handles many other security details. For example, they use SSL with strong 2048 bit keys for certificates.
A common first step in securing the app is identifying users. This process is called authentication. We use Firebase Authentication to have users to sign in to our app. Firebase Authentication includes drop-in support for common authentication methods like Google and Facebook, as well as email and password login, anonymous login, and more.
User identity is an important security concept. Different users have different data, and sometimes they have different capabilities. For example, in a chat application, each message is associated with the user that created it. Users may also be able to delete their own messages, but not messages posted by other users.
Identifying your user is only part of security. Once you know who they are, you need a way to control their access to data in your database. Firebase Database Rules allow you to control access for each user.
The Firebase Database Rules include built-in variables and functions that allow you to refer to other paths, server-side timestamps, authentication information, and more. Here’s an example of a rule that grants write access for authenticated users to /users/<uid>/, where <uid> is the ID of the user obtained through Firebase Authentication
“.write”: “$uid === auth.uid”
The Firebase Realtime Database is schemaless. This makes it easy to change things as you develop, but once your app is ready to distribute, it’s important for data to stay consistent. The rules language includes a .validate rule which allows you to apply validation logic using the same expressions used for .read and .write rules. The only difference is that validation rules do not cascade, so all relevant validation rules must evaluate to true in order for the write to be allowed.
These rule enforce that data written to /foo/ must be a string less than 100 characters
“.validate”: “newData.isString() && newData.val().length < 100”
Refer the link below for more on security rules in firebase real time DB
Note -: We may also use the following as we scale —
1. XMPP — The Extensible Messaging and Presence Protocol, a set of open technologies for instant messaging, multi-party chat, voice and video calls. XMPP servers allow us to transfer/receive messages between devices.
2. Smack Api — A highly modular and portable open source XMPP client library, written in Java, for Android. Used to send and read messages from the XMPP server.