DEV Community

To the Stars with Quasar & Firebase - User Profile

Adam Purdy on February 06, 2020

Table Of Contents Introduction 1.1 Assumptions Update User Creation Flow 2.1 Setup Cloud Firestore 2.2 Create the DB Service ...

Read full post

eosca • Jul 3 '20

Hello! I have a question. Why are you sometimes using vuex actions (insted of simple functions outside actions file, outside the store) if those actions are not commiting mutations? Are they actions or not?

Ex.: in file store/auth/actions.js -> routeUserToAuth, loginUser, or createNewUser...

Thanks for your work with firebase-quasar!

Adam Purdy • Jul 22 '20 • Edited

Hello, thanks for the question, and sorry for the late response. I’ve been away from my computer the past couple of months doing a bathroom remodel.

It’s more of a convention thing. You can easily do how you mentioned in a utility file or something else you like.

I tend to keep any interactions with the DB in actions, and technically most of those functions you mentioned touch Firebase and alter the user’s state. Keep in mind the use of the vuexfire. Once the user has logged in, a call is being made to the user’s collection or adding a new user, in the case of the createNewUser, which will get the currentUser’s info and put it into state via vuexfire.

The exception here is routeUserToAuth. Again, putting that function in an action file is just convention, as it’s a small sample app. I hope that answer's your question.

eosca • Jul 22 '20

Ok. Thank you! And good luck with reform.

David • Dec 27 '20

Thanks for the tutorial. How would I get the currentUser uid into my node server? I think this goes into my index.js file:
admin
.auth()
.verifyIdToken(idToken)
.then((decodedToken) => {
const uid = decodedToken.uid;

})
.catch((error) => {
// Handle error
});

But where do I put the code to get the token from the client?

firebase.auth().currentUser.getIdToken(/* forceRefresh */ true).then(function(idToken) {
// Send token to your backend via HTTPS
// ...
}).catch(function(error) {
// Handle error
});

Adam Purdy • Dec 28 '20

Set up your axios boot file with an intercepter.

import axios from "axios"
import firebaseService from "../services/firebase"

const api = axios.create({
  baseURL: "http://localhost:5000/api/v1"
})

export default ({ store, Vue }) => {
  api.interceptors.request.use(async req => {
    const token = await firebaseService.auth().currentUser.getIdToken()
    req.headers.Authorization = `Bearer ${token}`
    return req
  })

  Vue.prototype.$api = api
  store.$api = axios
}

David • Dec 29 '20

Hi Adam,
I appreciate the quick reply. I included that interceptor in my axios boot file. So the token can then be passed into index.js and then I can verify the user, but I am not understanding how to get the current user's uid into my node file...

Sorry for my ignorance, still learning!

Adam Purdy • Dec 29 '20

No problem!

Pass it from the client app via the API call by retrieving it from the currentUser that is loaded in your page from your Vuex getter.
Profile

You can extract out the uid from that currentUser object and then when you make your API call to your node server include it in your payload.

If this still doesn't make sense it's best if you reach out to me on Discord (Adam P(EN/US)) as you might need clarification on working with the data flow.

David • Dec 30 '20

Sounds good! Would you mind adding me as a friend? djsilvestri#5594

eosca • Sep 9 '20

Hello, your tutorial helps me a lot, thanks again!!!

I have another question... why did you code "return { ...this }" in the constructor of the class User??? I was copying your code in each class I was creating for my app and when I needed to invoke public methods I couldn't because of that. Now it's solved deleting the return of the constructor, but I am asking myself about the reason of that. Is there any reason?

eosca • Sep 14 '20

Firestore needs js pure objects... ok further problems help me to know why "return { ...this }"...

Adam Purdy • Sep 18 '20

Hello again. I typically do not use Classes in my javascript as I do not come from a classical programming background. I used a class here to abstract the user model, but I still use just a standard pure js object for object creations for Firestore as well.

In regards to your question: why return { ...this }.

When the user object is instantiated in the auth actions file, the email is being provided to the constructor. After the constructor has finished its loop and populated the prop or email, it then returns a pure js object by using the spread operator to populate all of the initial props and the update email prop.

I can not speak into why your public methods are not working, but feel free to move away from this pattern of setting up the User via a class or modify it to suit your needs.

gicelte • Jun 17 '21

Hi, thanks for the great article! I am interested in implementing role-based authentication with Firebase. Could you give some hints about how to extend the code you have provided to get a system able to manage administrators and normal users? Is this related to David's question below?

Adam Purdy • Jun 23 '21

Hey @gicelte you need to implement the setCustomUserClaims on the server side of things via Firebase Admin.

On my service side of things in my applications I just add a simple prop in the method call.

await admin.auth().setCustomUserClaims(authUser.uid, {
  isAdmin: true
})

Then will do an await call on the client to route the user based on perms set on the user's auth record coming back from Firebase auth.

This is a start but by no means a thorough approach as user roles can be extensive in an application. For an in-depth setup explanation of setCustomUserClaims try googling: 'role based auth with firebase admin tutorial'.

Hope that gave you enough to point you in the right direction.