Confusing use of root token in auth example


#1
if (!event.context.graphcool.pat) {
    console.log('Please provide a valid root token!')
    return { error: 'Facebook Authentication not configured correctly.'}
}

Line 4.

Anyone know why this is in the Facebook authentication example? I don’t see any reason for checking if there is a root token here, it’s not used in the function at all, and at first glance doesn’t seem to be in the other auth examples.

The Facebook token is in the event data, that seems to be all I need… so why do I need a check for a root token here?


#2

The facebookAuthentication method is already packed with ability to create new users. Because the create method and other GraphQL calls to the query require admin priviliges, the check for PAT is necessary.

It’s the api which requires the token, not the “code” itself.


#3

Hey matic, thank you for the response. When you reference the ability to create new users, are you talking about?:

return graphcool.generateAuthToken(graphcoolUserId, 'User') 

Because the user type declaration itself doesn’t seem to require any special permissions. I didn’t think there were default permissions, but perhaps I’m wrong. In any case, if the graphcool object generated by fromEvent requires admin level authentication then I suppose that sort of makes sense.

Also, why does the error report back that the Facebook Authentication is not configured correctly inside of the check for the root token? What does the Facebook authentication configuration have to do with the root token?

Also, can you help me better understand? When would rootToken not be available in this use case? Won’t it always be there so long as it is specified in the .yml? and if this is simply there to inform that the root token is required in the case that it wasn’t configured correctly, why is the error reporting back a facebook configuration problem…

idk, maybe I’m looking to much into this, the whole thing just seems a little cryptic and confusing.


#4

hey russel, sure, I’d love to further explain.

So, yes the use case of PAT that you provided also uses the PAT token, but it is actually a lot more general, as the fromEvent functions of graphcool-lib packs every query call with the token, if one is defined.

    if (token) {
      return new GraphQLClient(url, {
        headers: {
          Authorization: `Bearer ${token}`,
        },
      })
    } else {
      return new GraphQLClient(url)
    }

The Facebook Authentication is not configured correctly error is only a simple explanation of what is happening. You can change it however you want. As this module is meant to be used with no further investigation, it is a rather good explanation of what’s going on behind the scenes. It gives user instant feedback and spectrum of the function which returned error (Facebook Authentication function) and logs the problem that occurred.

PAT tokens have to be defined in the schema specifically. There is a separate section (usually at the bottom) of the file, which tells which functions should have PAT included. Hence, the name of the function must match the name of the PAT. If the function name is not included in the rootTokens section, the function will have no token in its context.

functions: 
   authenticate:
      handler:
         code: './resolver.js'
   ...etc

rootTokens:
   - authenticate

#5

Matic, thank you for taking the time to clear things up. That is more or less what I suspected but just hard to know when looking at a new technology when there is so much happening behind the scenes. I appreciate it.


#6

I must add to this, that all resolver functions get a generated rootToken automatically at the moment, whether you define one in your service definition or not. This means that the check really doesn’t need to be there. Also, it uses the deprecated pat field, so actually @russell you are right that this needs updating.

This piece of the code was part of the old template, where you wouldn’t get a pat in your context, if you didn’t define a pat on your project. This is no longer true.


#7

@agartha, ah that would explain why it’s not in the other auth examples. Makes sense now, thank you for clarifying.