Hi, community! Seems like an obvious question, but how do you guys handle Firebase Auth with Typesense Extension for Firestore? I mean not letting to do the search unless the user is logged w/ Firebase Auth or has certain roles? I guess we have to tie together logged user to TypeSense users collection and particular roles and eventually using scoped search key depending on the role/auth?

That’s correct. From Typesense’s perspective, access to records is controlled using scoped search api keys

Thanks for your input, @Jason Bosco If I understood correctly, in TS docs it says that all documents in searchable collection have to have an array with roles which can access that document. I was thinking though, would reading currentUserData from Firebase (e.g. their roles) and then send the role to TS and filter the results by that would be an option? Conditional rendering is of course an option, but security wise I guess it's not. In other words, is there a way to not let user search on TS collection is the user does not have certain role or is not logged in? Again, seems like an obvious question, but just trying to figure out the balance between data security and accessibility versus maybe unecessary completion.

I was thinking though, would reading currentUserData from Firebase (e.g. their roles)

You would have to do this on the backend (say in a Google Cloud function) - get the current role for the user (say RoleX), then generate a scoped API key on the fly which has an embedded filter in it, which has something like

filter_by:=roles:RoleX

, send that key to the frontend and have the FE use it to make API calls to Typesense.

Ok, I think I got it.. Have you seen any examples how people usually approach auth with TS, e.g. giving apiKey if person is logged in via Firebase Auth? Roles is the next step, but at the moment I am not sure how to "protect" the cloned Firestore data for search. If it changes anything, I am on NextJS / Firebase Auth setup.

If you’re not using roles, you’d want to have a user_id field in each record which indicates which user can access that record. Then when a user logs in, you’d create a similar scoped search api key, but instead of a role filter, you’d use an embedded filter like userid:=123 where 123 is the logged in user’s ID

I think you misunderstood me here a little, although a great help with future ideas! By not using roles, I literally mean just give access to TS collection if user is simply logged via Firebase Auth to the system (that's an internal company system with 30+ users). Because right now the user can only fetch Firestore collections if they are logged in (and have certain roles) via read/write rules. I am just trying to figure out how to get the same result with TS, because essentially TS collection is a clone of FS, just with no read rules. It's easily doable on the front end, but security is a concern. I was even thinking of add a search key attribute to each user (or the ones which have access) and once they log in, along with other user data, they get the search key which is then used for TS as well. I understand that the key is exposed to logged user, but that's not a concern. Also, your very prompt support and help is extremely appreciated, thank you for that. The product is great, love the speed of it and a lot of ideas in the future!

Ah I see, when a user logs in, I would still recommend making an API call to a Google Cloud function, ensuring that the user is logged in to Firebase auth once again, then if they are, make an API call to Typesense from the Google cloud function to create a unique API key for that user, and send that to the frontend to make Typesense api calls using it. Then you could set a short expires_at on that key and repeat the above process of you notice the API key has expired. Finally when the user logs out, you want to delete the API key from Typesense using a similar Google cloud function. The important thing here that ensures security is that you’re verifying that the user is logged in to Firebase auth in the Google cloud function, before generating the api key