JEN PERSON: I've noticed that a horse
neighing sounds very similar to, like, a machine gun.
[NEIGHING]
Like, I don't know.
FRANK VAN PUFFELEN: Dutch horses make different sounds,
if you noted that.
JEN PERSON: Oh!
What does a Dutch horse say?
FRANK VAN PUFFELEN: [NEIGHING]
JEN PERSON: Wow, that was really good.
See?
That's what I'm trying to do.
And this is all I've got.
[MUSIC PLAYING]
FRANK VAN PUFFELEN: Scene one, take one, [INAUDIBLE]..
JEN PERSON: Hey, all you Firebase developers.
Welcome to another episode of #AskFirebase, the show
where we answer your burning Firebase questions.
I'm your host, Jen Person.
And today, my co-host is Frank van Puffelen.
FRANK VAN PUFFELEN: Hey, everyone.
JEN PERSON: Also known as Puff.
FRANK VAN PUFFELEN: That's me.
So I liked the burning Firebase questions in there, by the way.
JEN PERSON: You know, it came out once.
And now, it just stuck.
I really enjoy--
FRANK VAN PUFFELEN: Yeah, that's a really good one.
JEN PERSON: I enjoy any kind of play on words, honestly.
FRANK VAN PUFFELEN: More.
JEN PERSON: Are you ready for your first question?
FRANK VAN PUFFELEN: More questions,
bring them, bring them, bring them.
JEN PERSON: So our next question comes
from @trappology on Twitter.
And I know it says, hey, @asciimike, but--
FRANK VAN PUFFELEN: Yeah, Mike is a bit busy right now.
We swear he's doing well, but busy.
JEN PERSON: Yeah.
FRANK VAN PUFFELEN: So I'll take this one for him.
JEN PERSON: Cool.
Thank you.
Any insight into what makes a Firebase download URL
unguessable?
Is there are just too many possible outcomes,
any restrictions on attempts, or, you know,
why is it unguessable?
FRANK VAN PUFFELEN: Ah, that's a good one.
Let's do a simple one, right?
I'm going to try and think of number between one and five,
and you need to guess it.
JEN PERSON: OK.
FRANK VAN PUFFELEN: So, go for it.
JEN PERSON: Four.
FRANK VAN PUFFELEN: No.
JEN PERSON: Two.
FRANK VAN PUFFELEN: No.
JEN PERSON: Whatever I say, you're
just going to say no until I get to the last number.
FRANK VAN PUFFELEN: No, no, no.
That's not true.
JEN PERSON: OK, OK.
One.
FRANK VAN PUFFELEN: No, you're really--
OK.
JEN PERSON: Five.
FRANK VAN PUFFELEN: You really have one number left.
JEN PERSON: No way.
OK, so you're saying it was three.
FRANK VAN PUFFELEN: It was actually indeed number three.
JEN PERSON: OK.
It really looks like we planned this, but--
FRANK VAN PUFFELEN: Let's do this one again, because--
JEN PERSON: Are you serious?
FRANK VAN PUFFELEN: I'll pick whatever numbers that you
say the second time, I guess.
It really was three.
JEN PERSON: No, but see, that's true.
FRANK VAN PUFFELEN: OK.
JEN PERSON: I mean, honestly, you proved it.
FRANK VAN PUFFELEN: Yeah.
So, I'm going to pick a number between one and five,
and I want you to guess it.
JEN PERSON: OK.
FRANK VAN PUFFELEN: Go.
JEN PERSON: Three.
FRANK VAN PUFFELEN: See?
You guessed it at the first one.
So now we're going to do another guess, right?
I'm going to pick a number between 1 and 100,000.
Go.
JEN PERSON: 5,280.
FRANK VAN PUFFELEN: No.
JEN PERSON: Right.
We're going to be here a minute.
FRANK VAN PUFFELEN: Yeah, exactly.
And this is the reason that, actually, download URLs
are unguessable.
What we've done is we've added a very long, random number
at the end.
And the number is so long that you cannot reasonably guess it.
Right?
And that means that, if somebody wants to find the image,
they have to first know the path to the image.
And then, they have to guess a--
what was it--
128-bit string that we have there.
So that's 2 to the 128th bits of randomness, as we call it.
So that's, let's see, 3.4--
I actually don't even know how many zeros we have in there.
Right?
That's a huge number.
And the chances of guessing that number on your first try
or on any try are actually pretty much zero.
JEN PERSON: Even if you're setting up
some sort of function that just does it through a brute force
approach, I hope you're willing to wait a few hundred years.
FRANK VAN PUFFELEN: Yeah, exactly.
You'll see that we do this a lot, actually, in Firebase.
Right?
Let me see.
For example, push IDs in the Realtime Database
are also just random numbers, but also
with a lot of bits of randomness.
Or, let's see, document IDs in Cloud Firestore
are also just GUIDs, Globally Unique Identifiers.
So there's no chance that somebody can reasonably
guess the download URL of your images,
and that's why they are safe to share.
JEN PERSON: And if someone does guess,
they should probably play the lottery as well.
FRANK VAN PUFFELEN: That's actually a good one.
That's probably better than finding the image on Cloud
Storage for your project.
JEN PERSON: That's true.
Yeah.
Statistically, it's probably easier to win the lottery.
FRANK VAN PUFFELEN: That's a good one, actually.
JEN PERSON: Wow.
FRANK VAN PUFFELEN: Since you guessed my number three in one
go, maybe we should actually find some scratchers.
JEN PERSON: Yeah.
What are we even doing here?
Let's just go win the lottery.
FRANK VAN PUFFELEN: Three was the number.
JEN PERSON: You're always ready for the next one.
FRANK VAN PUFFELEN: Of course.
JEN PERSON: OK.
So our next question comes from Luke.
He wants to know, are we charged for validate reads
in the Realtime Database?
FRANK VAN PUFFELEN: Oh, good question, Luke.
So validate reads are part of Firebase's security rules.
And we run those on the server whenever
somebody accesses the data.
And the validate is when they write the data.
So the simple answer is no.
Actually, in the Realtime Database,
you are not charged for any of the operations
by security rules.
So, it doesn't matter if you need to access other data.
It's included in the charge that we do for other operations,
so no specific charges for reads in your security rules.
This is different, though, from Cloud Firestore.
In Cloud Firestore, we have a new rule system.
And we give you a lot more abilities,
but that does mean that you will be
charged when you read a document from somewhere
else in the database.
So say that you store something like a group
membership in a separate set of documents in the database,
then if you need to read that group membership to verify
if a user has access to a certain collection,
then you will be charged for the reading of that document.
JEN PERSON: Which is why I am always trying to champion using
Firebase Auth Custom Claims.
Now, there are some certain situations
where, if someone is going to be a member of a whole lot
of groups or something like that,
probably just storing that in the database is better.
But otherwise, adding a little bit of information
to the Firebase auth token can enable you to identify,
in your rules, what people can access without having to read
the database every time.
Also, it works in Cloud Storage, Cloud Firestore,
and Realtime Database.
So you can secure those rules across all three
of those, which I think is especially important for Cloud
Storage.
Sometimes people ask, well, I have this information
in Firestore about what groups these people are in,
but I can't access that from Cloud Storage rules.
So, definitely look into that.
FRANK VAN PUFFELEN: Yeah.
That's a great reason indeed to use
Custom Claims in your tokens.
But reading from a document, also a totally valid option.
JEN PERSON: Absolutely.
Try them both.
FRANK VAN PUFFELEN: Yeah, and see what works best for you.
JEN PERSON: If you've got a whole bunch of groups
that someone's going to be a part of,
it's probably best to use the Firestore, or whatever
database, to store them, because you
do have a limit in the number of Custom Claims you have.
FRANK VAN PUFFELEN: That's actually such a good question
that we covered it in one of our talks
at the Firebase Summit last year.
So we're going to include a link in the description
down below to find out more, and the video
is called Five Quick Tips For Securing Your Firebase App.
JEN PERSON: We have yet another question.
Are you ready?
FRANK VAN PUFFELEN: Yes.
Let's bring these on.
JEN PERSON: We're just rapid-firing them.
You're, like, ready to go.
I love it.
FRANK VAN PUFFELEN: Of course.
JEN PERSON: Garret Kaye says, is there
a different way I can select random documents
in Cloud Firestore?
FRANK VAN PUFFELEN: Well, I don't
know what the original way was that was proposed,
but there are a few ways that you
can select random documents.
And this one is actually interesting,
because I did not come up with the answer.
I actually learned this one from Dan McGrath,
who's the product manager for Cloud Firestore.
He gave a great answer in Stack Overflow,
so we'll also link that in the description below.
But there is roughly two approaches.
And I'll start with the simplest one, which is not the one
that I initially was using.
It's definitely not the one that most people start with.
The simplest one is actually, when you create the documents,
insert a random value in the documents.
So just do math.random if you're using JavaScript.
You'll get a value between 0 and 1.
Right?
And it doesn't really matter what it is,
just store it in the document.
Now, if you do that for all your documents,
then write each document has a random value.
So now when you want to query and find a random document,
you, in your client side code, determine a random value
between 0 and 1 again.
And then you say, order on the random fields.
Start at the random value that you've calculated.
So you have your collection, you order it
on the field that has the random value,
and then you start at the random value that you've calculated.
And then you just limit it to one document.
If you do that, you get a random document.
It's actually really quite simple
once you have the right data structure
in place, which is fairly common on NoSQL databases.
JEN PERSON: Yeah.
You know, I actually used a very similar strategy
when Hiranya and I gave our talk on incorporating Firebase
into your existing backend infrastructure.
FRANK VAN PUFFELEN: Cool.
JEN PERSON: So you know, I worked on the frontend, which
shows just a series of movies.
And I really wanted it to show a random series of movies
every time.
So each time you come in, you could be like,
oh, I've seen that.
I'll review it.
I want to see this.
I'll add it to my viewing lists so I can check it out later.
And so, we got the information from TMDb, The Movie Database.
And each of those has a unique identifier.
I believe they're all, maybe, four digits or something.
So I used that, similarly.
I generated a random number between, whatever it was,
1 and 0 and 10,000.
And then, I would start at that particular value
and go from there.
And it seemed to work very well.
I was a little worried on stage, because it's
absolutely every movie, that something might come up
when I clicked refresh.
But it seemed to work really well.
FRANK VAN PUFFELEN: Yeah, no, I can totally get that.
And that's actually right.
You know the range of numbers that you have,
which is the thing that, in this case, you would need.
JEN PERSON: You have to have it, yeah.
FRANK VAN PUFFELEN: Yeah, and that's
why if you do a random number, just do math.random.
It's a number between 0 and 1, right?
And that means that you know the range.
But it's not a whole number, which is, in your case,
it wasn't a whole number.
JEN PERSON: Right.
Yes, because it just already happened to have that field.
But I think if I didn't have some unique identifier
of each movie, I would do something
like what you're describing.
FRANK VAN PUFFELEN: Did you have to show a single movie
or multiple random movies?
JEN PERSON: Multiple movies.
FRANK VAN PUFFELEN: How did you do that?
JEN PERSON: I just said, start at and ordering.
I had it descending.
FRANK VAN PUFFELEN: Right.
So you got one random number right in the client,
and then you streamed results from that, right?
So you took that one and the next two IDs probably, right?
JEN PERSON: Exactly.
Yeah, so it's like a small amount of time.
Sure, there is the possibility that I
could pick the exact last movie, but it's pretty unlikely.
FRANK VAN PUFFELEN: Yeah, the thing there
is you get a sequence.
And if you would ever get the same random number again,
you would get the same sequence.
JEN PERSON: That's true.
FRANK VAN PUFFELEN: Which was fine for your app, apparently.
If that is not fine for the app that you are building,
then you would actually have to generate a new random number
for each of them.
JEN PERSON: Every single one.
FRANK VAN PUFFELEN: But keep in mind,
Cloud Firestore is quite efficient at retrieving
these types of documents with multiple calls.
So it's not a performance problem [INAUDIBLE]
JEN PERSON: Cool.
FRANK VAN PUFFELEN: Hey, Jen.
The next question is for you.
JEN PERSON: Oh, wow.
FRANK VAN PUFFELEN: @mohitthatte says on Twitter,
Frank van Puffelen is my favorite dev rel person!
That's not a question, but I like the statement.
And he answers Firebase-related questions
from Twitter and Stack Overflow on a YouTube channel.
Love his personality, #AskFirebase.
What?
Tell me, Jen.
JEN PERSON: I just wanted to include that.
Thank you.
I thought that was really thoughtful.
We really appreciate having Puff on the team as well.
He is just invaluable.
We could not do what we do without you.
So, absolutely love it, thanks for your feedback.
I was like, if you're going be on the show, I might as well--
FRANK VAN PUFFELEN: Nice, nice, nice.
JEN PERSON: --throw it up there.
FRANK VAN PUFFELEN: Thank you, Mohit.
I honestly appreciate it.
Answering questions is typically my favorite part of the day.
But thank you for the recognition,
and thanks for the shoutout, much appreciated.
JEN PERSON: And thank you for coming on yet again.
It's so wonderful to have you on here.
FRANK VAN PUFFELEN: Are we done already?
JEN PERSON: Yeah, that's it!
FRANK VAN PUFFELEN: OK.
JEN PERSON: And thank all of you for your questions.
We really can't make this show without you.
So when you have some sort of Firebase question,
be sure to put on social media with the hashtag #AskFirebase.
And who knows?
Maybe, you'll see Puff answering it on a future episode.
FRANK VAN PUFFELEN: That would be cool.
JEN PERSON: Yeah.
And if you like the content that you see here,
Subscribe to the Firebase YouTube
channel where you can see all sorts of other cool shows
as well.
Thanks so much for watching, and we'll
see you on a future episode.
[MUSIC PLAYING]
(SINGING) Ding, ding, ding, ding, ding.
I'm just making up another song.
That's not even how it goes.