This article is the second part of the Flutter tutorial series. During the series, you will learn how to build cross-platform apps without worrying about the backend.
In this article, I will show you how you can make a secure chat application by introducing authorization to the basic chat app that we created previously.
We will store the chat data on Supabase.
Supabase utilizes the built in authorization mechanism of PostgreSQL called Row Level Security or RLS to prevent unauthorized access from accessing or writing data to your database.
RLS allows developers to define row-by-row conditions that evaluate to either true or false to either allow the access or deny it.
We will take a look at more specific examples of authorization using RLS throughout this article.
Before we jump in, let's go over what we built in the previous article, because we will be building on top of it. If you have not gone through it, I recommend you to go check it out.
In the previous article, we created a basic real-time chat application. Users will register or sign in using an email address and password. Once they are signed in, they are taken to a chat page, where they can view and send messages to everyone in the app. There are no Chat rooms, and everyone's messages were sent to the same chat room.
You can also find a complete code example here to follow along.
The app will allow us to have 1 on 1 chat with other users in the app. To enable this, we will introduce a new rooms page. The rooms page serves two purposes here, one is to initiate a conversation with other users, and the other is to display existing chat rooms. At the top of the app, we see a list of other users' icons. A user can tap the icon to start a 1 on 1 conversation. Below the icons, there is a list of rooms that the user is a part of.
We will install flutter_bloc for state management.
Introducing a state management solution will allow us to handle the shared message and profile data efficiently between the rooms page and the chats page.
We can use any state management solution for this, but we are going with bloc in this example.
Add the following in your pubspec.yaml file to install flutter_bloc in your app.
Since the app has evolved, we also need to update our table schema. In order to store rooms data, we will add a rooms table. We will also modify the messages table to add a foreign key constraint to the rooms table so that we can tell which message belongs to which room.
We will also introduce a create_new_room function, which is a database function that handles chat room creation. It knows to create a new room if a chat room with the two users does not exist yet, or to just return the room ID if it already exists.
-- *** Table definitions ***
create table if not exists public.rooms (
id uuid not null primary key default gen_random_uuid(),
created_at timestamp with time zone default timezone('utc' :: text, now()) not null
);
comment on table public.rooms is 'Holds chat rooms';
create table if not exists public.room_participants (
profile_id uuid references public.profiles(id) on delete cascade not null,
room_id uuid references public.rooms(id) on delete cascade not null,
created_at timestamp with time zone default timezone('utc' :: text, now()) not null,
primary key (profile_id, room_id)
);
comment on table public.room_participants is 'Relational table of users and rooms.';
alter table public.messages
add column room_id uuid references public.rooms(id) on delete cascade not null;
-- *** Add tables to the publication to enable realtime ***
alter publication supabase_realtime add table public.room_participants;
-- Creates a new room with the user and another user in it.
-- Will return the room_id of the created room
-- Will return a room_id if there were already a room with those participants
create or replace function create_new_room(other_user_id uuid) returns uuid as $$
declare
new_room_id uuid;
begin
-- Check if room with both participants already exist
with rooms_with_profiles as (
select room_id, array_agg(profile_id) as participants
from room_participants
group by room_id
)
select room_id
into new_room_id
from rooms_with_profiles
where create_new_room.other_user_id=any(participants)
and auth.uid()=any(participants);
if not found then
-- Create a new room
insert into public.rooms default values
returning id into new_room_id;
-- Insert the caller user into the new room
insert into public.room_participants (profile_id, room_id)
values (auth.uid(), new_room_id);
-- Insert the other_user user into the new room
insert into public.room_participants (profile_id, room_id)
Something we skipped in the previous article was sending confirmation emails to users when they signup. Since today is about security, let's properly send confirmation emails to people who signup.
When we send confirmation emails, the users need to be brought back to the app somehow.
Since supabase_flutter has a mechanism to detect and handle deep links, we will register a io.supabase.chat://login as our deep link for the app and bring the users back after confirming their email address.
For iOS we edit the info.plist file to register the deep link.
<!-- ... other tags -->
<plist>
<dict>
<!-- ... other tags -->
<!-- Add this array for Deep Links -->
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleTypeRole</key>
<string>Editor</string>
<key>CFBundleURLSchemes</key>
<array>
<string>io.supabase.chat</string>
</array>
</dict>
</array>
<!-- ... other tags -->
</dict>
</plist>
For Android we edit the AndroidManifest.xml to register the deep link.
<!-- Accepts URIs that begin with YOUR_SCHEME://YOUR_HOST -->
<data
android:scheme="io.supabase.chat"
android:host="login" />
</intent-filter>
</activity>
</application>
</manifest>
We also need to set the deep link in our Supabase dashboard. Go to Authentication > URL Configuration in your dashboard and add io.supabase.chat://login as one of the redirect URLs.
The rooms page will load two types of data, recently added users and a list of rooms that the user belongs to. We will be using bloc to load these two types of data and display them on the rooms page.
Let's start out by creating states for the rooms page.
The rooms page would have four different states, loading, loaded, empty, and error. We will display different UI on the rooms page depending on what state it is.
Satrt by defining the Room model. Create a lib/models/room.dart file and add the following code.
import 'package:my_chat_app/models/message.dart';
class Room {
Room({
required this.id,
required this.createdAt,
required this.otherUserId,
this.lastMessage,
});
/// ID of the room
final String id;
/// Date and time when the room was created
final DateTime createdAt;
/// ID of the user who the user is talking to
final String otherUserId;
/// Latest message submitted in the room
final Message? lastMessage;
Map<String, dynamic> toMap() {
return {
'id': id,
'createdAt': createdAt.millisecondsSinceEpoch,
};
}
/// Creates a room object from room_participants table
We will proceed with defining the states for the rooms page. Create lib/cubit/rooms/rooms_state.dart file and paste the following code.
You may see some errors, but we will take care of them in the next step.
part of 'rooms_cubit.dart';
@immutable
abstract class RoomState {}
class RoomsLoading extends RoomState {}
class RoomsLoaded extends RoomState {
final List<Profile> newUsers;
final List<Room> rooms;
RoomsLoaded({
required this.rooms,
required this.newUsers,
});
}
class RoomsEmpty extends RoomState {
final List<Profile> newUsers;
RoomsEmpty({required this.newUsers});
}
class RoomsError extends RoomState {
final String message;
RoomsError(this.message);
}
Now that we have the states defined, we will create rooms_cubit.
A cubit is a class within the flutter_bloc library where we will make requests to Supabase to get the data and transform them into states and emit them to the UI widgets.
Let's create a lib/cubit/rooms/rooms_cubit.dart file and complete the cubit.
Now that we have the states and cubit to power our rooms page, it's time to create the RoomsPage.
We have two list views, one horizontal list view to display other users, and one vertical list views with list tiles representing each room that the user is a part of.
We will create a lib/pages/rooms_page.dart file with the following content.
You may see some errors, but they will go away once we edit the chat page!
Step 2: Modify the chat page to load messages in the room#
Our ChatPage will have a similar layout as the previous one, but will only display messages sent to a single room. We will start by creating MessagesState. The messages page will also have four different states, loading, loaded, empty, and error.
Create a lib/cubits/chat/chat_state.dart file with the following code.
part of 'chat_cubit.dart';
@immutable
abstract class ChatState {}
class ChatInitial extends ChatState {}
class ChatLoaded extends ChatState {
ChatLoaded(this.messages);
final List<Message> messages;
}
class ChatEmpty extends ChatState {}
class ChatError extends ChatState {
ChatError(this.message);
final String message;
}
Now let's create chat cubit to retrieve the data from our database and emit it as states.
Create a lib/cubits/chat/chat_cubit.dart file and paste the following.
Chat cubit is pretty simple. It sets a real-time listener to the database using the stream method and emits an empty state if there are no messages in the room, or emits a loaded state if there are messages.
Because we are using cubit, we need to modify the MessagesPage widget as well.
Open lib/pages/chat_page.dart and let's update it.
Because we have modified the setting of our Supabase to send a confirmation email, we need to make some modifications to the register page and login page as well.
The main change is how we handle navigation.
Previously, we were able to navigate the user to ChatPage right after sign-in was complete.
This would no longer work, as we now have to wait for the user to confirm their email address.
In this case, we would want to listen to auth state of the user and navigate when the user is signed in with a session.
This allows us to react when the user confirmed their email addresses.
return '3-24 long with alphanumeric or underscore';
}
return null;
},
),
spacer,
ElevatedButton(
onPressed: _isLoading ? null : _signUp,
child: const Text('Register'),
),
spacer,
TextButton(
onPressed: () {
Navigator.of(context)
.push(LoginPage.route());
},
child:
const Text('I already have an account'))
],
),
),
);
}
}
Login page becomes simpler.
All it is doing is taking a user's email and password and logging them in.
It is not doing any navigation whatsoever.
This is because LoginPage is navigated on top of RegisterPage, the auth state listener on RegisterPage is still active, and therefore can take care of the navigation.
Notice that I have not used bloc anywhere on the register or login page.
I try to only use state management libraries for pages that have some complexity.
Since both register and login pages are relatively simple, I am going with the good old setState.
We should also modify the splash page to redirect signed-in users to the RoomsPage by default.
// quick and dirty way to wait for the widget to mount
await Future.delayed(Duration.zero);
try {
final session =
await SupabaseAuth.instance.initialSession;
if (session == null) {
Navigator.of(context).pushAndRemoveUntil(
RegisterPage.route(), (_) => false);
} else {
Navigator.of(context).pushAndRemoveUntil(
RoomsPage.route(), (_) => false);
}
} catch (_) {
context.showErrorSnackBar(
message: 'Error occurred during session refresh',
);
Navigator.of(context).pushAndRemoveUntil(
RegisterPage.route(), (_) => false);
}
}
@override
Widget build(BuildContext context) {
return const Scaffold(
body: Center(child: CircularProgressIndicator()),
);
}
}
Finally we implement those ProfilesCubit that you saw here and there throughout the code.
This cubit will act as in memory cache of all the profiles data so that the app does not have to go fetch the same profiles every single time it needs it.
Create profiles_state.dart and profiles_cubit.dart under lib/cubits/ and add the following code.
Step 4: Authorization with Row Level Security (RLS)#
At this point, we seemingly have a complete app. But if we open the app right now, we will see every users' room along with all the messages that have ever been sent.
This is because we have not set up Row Level Security to prevent users from accessing rooms that don't belong to them.
There are two ways we can define Row Level Security policies in Supabase: with the GUI or through SQL. Today we will use SQL.
Let's run the following SQL to set the security policy.
-- Returns true if the signed in user is a participant of the room
create or replace function is_room_participant(room_id uuid)
returns boolean as $$
select exists(
select 1
from room_participants
where room_id = is_room_participant.room_id and profile_id = auth.uid()
);
$$ language sql security definer;
-- *** Row level security polities ***
alter table public.profiles enable row level security;
create policy "Public profiles are viewable by everyone."
on public.profiles for select using (true);
alter table public.rooms enable row level security;
create policy "Users can view rooms that they have joined"
on public.rooms for select using (is_room_participant(id));
alter table public.room_participants enable row level security;
create policy "Participants of the room can view other participants."
on public.room_participants for select using (is_room_participant(room_id));
alter table public.messages enable row level security;
create policy "Users can view messages on rooms they are in."
on public.messages for select using (is_room_participant(room_id));
create policy "Users can insert messages on rooms they are in."
on public.messages for insert with check (is_room_participant(room_id) and profile_id = auth.uid());
Notice that we have created a handy is_room_participant function that will return whether a particular user is a participant or not in a specific room.
With the Row Level Security policies set up, our application is complete. We now have a real-time chat application with proper authentication and authorization in place.
Continuing from our previous article, we added proper authorization to our chat application using Row Level Security, which enabled us to add 1 on 1 chat feature.
We used bloc for our state management solution. One thing we could have done differently if we were to write test codes was to pass the supabase instance as a parameter of the cubit so that we could write tests using the bloc_test package.
We could also explore some cool feature improvement.
At the top of the rooms page, we are loading the newest created users to start a conversation. This is fine, but it only allows users to start a conversation with new users.
We can for example update this to a list of users that are online at the same time. We can implement this using the presence feature of Supabase.