00:05
So as made evident by the fact that we were able to
00:07
successfully register a brand new user
00:08
inside of our application a couple of lessons ago,
00:11
we already have web authentication set up
00:13
and ready to go inside of this application.
00:16
So what we need to do is add API,
00:19
opaque access token authentication on top of it.
00:22
That's what we'll use to authenticate against
00:25
our organization inside of
00:26
our API that we'll be building throughout this series.
00:29
So similarly to how we
00:31
reconfigured our database inside of this application,
00:34
we're going to be redoing that with our authentication.
00:38
Really all that we want is a new AuthConfig generated out,
00:42
so that we also have the API guard
00:44
defined inside of our AuthConfiguration.
00:46
Now, we don't want to get rid of the web guard here,
00:49
so we want to merge what we currently have with
00:52
the new configuration that we'll get set up here in a moment.
00:55
But the configuration step won't give us
00:57
a new Auth file if it already exists inside of our file tree.
01:00
So in order to get a new Auth file,
01:03
let's right-click our Auth and just rename it here,
01:06
adding the suffix -web or something,
01:08
and then we'll be able to merge this into the new one,
01:11
and then we'll be able to delete this file.
01:12
So now that we have that set,
01:13
let's jump back into our terminal here and reconfigure Auth.
01:16
So node ace configure@adonisjs/auth,
01:21
give that a run, and it's going to ask us
01:23
which guard we want to use.
01:24
Now, session is the web guard that we already have set up,
01:27
so that's not the one that we want.
01:29
What we want is the opaque access tokens,
01:31
which is what we'll use to authenticate
01:33
against our organization with our API.
01:36
So give that a select,
01:37
and you should see that this generated out
01:40
a couple of files.
01:40
First and foremost, we have a new Auth configuration.
01:43
It also updated our adonisrc.ts file,
01:46
gave us a migration that we'll be deleting here
01:48
because we already have a user migration.
01:50
Our API is also going to be going against our organization
01:53
and not our user.
01:54
So we definitely don't need that migration,
01:56
but the second one we do want to keep.
01:58
This is the table that our access tokens
02:01
are actually going to store inside of.
02:03
So we definitely want that one there.
02:04
And then it skipped over giving us a new user model
02:08
since that already exists, as well as an auth middleware
02:10
since that exists as well, and it updated our kernel.ts.
02:14
So with all those in place,
02:14
let's go ahead and jump back into our text editor here,
02:17
and let's start by joining our web guard
02:19
together with our new Auth configuration for our API guard.
02:24
So if we just drag the new Auth configuration over here
02:27
onto the left-hand side,
02:28
keep the old one that we had for our web on the right,
02:30
you can see that really the only difference here
02:33
is the guards object itself.
02:35
Our old configuration has the guard for web
02:37
and our new configuration has the guard for our API.
02:40
So all we need to do here is copy the web guard
02:43
from our auth web file over into our new Auth configuration.
02:48
We can go ahead and move our cursor
02:49
to one of the red squigglies,
02:50
hit command dot to get the quick fix options.
02:53
And just select add all missing imports.
02:56
Then let's go ahead and switch our default guard back to web
02:59
so that if we omit specifying a guard with the authenticator,
03:04
it will default to using the web guard.
03:06
Since the web portion of this application predates,
03:09
the API portion we'll be adding throughout the series.
03:11
That's just going to make sure
03:12
that everything works properly for what's already there.
03:16
With that set, we're now done
03:17
with our auth web configuration file.
03:19
So we can close that out, right-click it,
03:21
delete and move it to the trash.
03:23
Now, as I've said a few times,
03:25
our API is going to authenticate
03:27
against our organization, not our user.
03:29
So we don't want this model to point towards our user here,
03:33
but rather we want it to point
03:35
towards our organization model.
03:37
We do however, still want to maintain our web guard
03:41
pointing towards our user there.
03:43
So the main difference here is whenever we log in
03:45
with the web guard, the authenticated user
03:48
that we're going to get back is an actual user record
03:51
of type user model.
03:52
Whenever we authenticate now with our API,
03:55
it will instead be an organization record
03:58
of type organization model.
04:00
So there is a difference there,
04:02
and it's going to vary depending on what auth guard
04:05
it is that we're actually using.
04:06
And whenever we fall back to that default guard,
04:09
it's actually not going to be able to differentiate
04:12
between those two different types
04:14
on which one it should use.
04:15
So it's going to give us a union of those two types.
04:18
Before we dive into that a little bit further,
04:20
let's fix the red squiggly here for our organization itself.
04:24
This is red squiggly because it doesn't implement
04:26
the access token provider that actually enables us
04:29
to create, delete, and manage our access tokens
04:32
for our organization.
04:33
So we need to go do that next.
04:35
And that's going to be within our app,
04:37
models, organization model.
04:40
Now the user model that it skipped over generating for us
04:43
would have had this already,
04:44
but what we now need to do is implement it
04:46
for our organization since we don't want it on our user
04:50
and it skipped over creating our user.
04:51
So at the top of our organization model here,
04:54
let's add in a static access tokens property
04:57
equal to DB access tokens provider.
05:02
Off of this class, we want to call for model
05:04
and pass in our organization model.
05:07
If you want a basic implementation,
05:08
that's all that you need,
05:10
but let's go ahead and configure this a little bit further.
05:12
If we actually dig into for model,
05:14
we can take a look at those types.
05:16
So I just command clicked on that type.
05:18
And if we scroll on over here,
05:19
we should see our options.
05:21
Now this is omitting tokenable model.
05:23
So keep that in mind.
05:24
But if we take a look at the types here,
05:26
we have tokenable model, which is being omitted,
05:28
table expires in token secret length type and prefix.
05:33
Prefix allows us to specify any string that we want
05:35
to actually be prefixed onto the token itself.
05:38
So if we wanted all of our generated tokens
05:40
to start with API, we could add that as a prefix.
05:43
And then all of our generated tokens
05:45
will then start with API as we've defined.
05:47
Type is a way for us to differentiate
05:49
between the access tokens
05:50
if our application needed multiple access tokens.
05:53
In our case, it doesn't,
05:54
but if we were to add access tokens
05:56
for anything else down the road,
05:58
in addition to our organization,
06:00
that would give us a way to have
06:02
our organization access tokens
06:04
in addition to whatever the other purpose is for them.
06:07
Token secret length is the actual secret length
06:10
of the token.
06:11
Expires in is the duration
06:13
that the token itself will be valid for.
06:15
So you might have it expire in 24 hours,
06:18
48 hours, two hours, you could set that there.
06:22
And then table is the table
06:24
that the access token itself should target.
06:26
So those are all of the options that we have there.
06:29
Although we don't need them,
06:30
we're gonna go ahead and fill a couple of them out.
06:32
So for our organization,
06:33
I'm gonna give these tokens a unique type called API token.
06:37
And then I'm also going to go ahead
06:38
and prefix all of my tokens with API underscore.
06:42
So this will specify that all of the tokens
06:44
created for our organization with this access tokens here
06:47
is specifically for purpose with our API.
06:50
And then we're just prefixing
06:51
the actual token itself with API
06:53
to give us a visual representation
06:55
of what that token's for.
06:56
And then the expiry,
06:58
if we don't specify an expiry within here,
07:00
we can specify it on a per token basis
07:03
whenever we create the token itself.
07:05
But if it's omitted in both places,
07:06
then the token will just never expire,
07:08
which is what we actually want for this application
07:11
since the user has a dashboard
07:12
where they can manage their tokens themselves.
07:15
So we're good to go there.
07:16
Let's go take a look at those migrations next.
07:18
So we'll dig into our database migrations.
07:20
These two green files are the ones that were created for us.
07:23
As stated earlier,
07:24
we actually wanna get rid of our user one
07:25
because we already have a user migration up here
07:28
that adds everything in for our user itself.
07:31
So we'll just right click on that one,
07:32
delete it and move that to the trash.
07:35
The second one that was generated for us
07:36
is our auth access tokens table.
07:39
And this has everything almost exactly as we need it.
07:42
First and foremost,
07:43
we need to change the foreign key for the tokenable ID.
07:47
Tokenable ID is the actual ID
07:49
for the record the token was created for.
07:51
So in this case,
07:52
it's going to be our organization ID
07:54
that the token is actually for.
07:56
So we don't want it to reference our users table,
07:58
but rather the ID inside of our organizations table.
08:02
In addition to that,
08:03
since this is bound to our organization,
08:05
let's rename the table itself
08:07
to match with the other namings
08:08
that we have on our organization's API access tokens
08:11
by renaming this from auth access token
08:14
to instead API access tokens.
08:16
Since we've now switched this default name,
08:19
we also want to reference that
08:20
inside of our organization access tokens configuration
08:23
as well by adding table API access tokens
08:28
to make sure that both of those match.
08:30
With that set, we can go ahead and run this migration.
08:32
So let's jump back into our terminal
08:34
and do node ace migration run.
08:38
And there we go.
08:39
Okay, we can clear our terminal out there.
08:40
Then briefly before we run this lesson out,
08:42
let's quickly discuss the actual authenticator types
08:47
that I touched upon a moment ago.
08:48
So let's do a quick search within our application here
08:51
for auth.user.
08:54
All right, looks like we have this
08:55
within our organization controller right here.
08:57
Whenever we reference auth.user,
08:59
that's going to use the default guard
09:01
from our auth configuration, which I have right here.
09:04
So I'm just going to drag this over to the right hand side
09:06
so that we have those side by side.
09:07
So our default guard is web,
09:09
and that's the one that this will use.
09:11
But remember, I mentioned that it's going to be a union type
09:14
since whenever we use the default guard,
09:16
TypeScript's not going to be able to discern
09:18
which model we're actually using between these two guards.
09:22
So if we take a look at the type of our auth.user,
09:24
you'll see that it's user or organization,
09:27
and then our access token bound on top of it,
09:30
which is added on by the tokens guard
09:31
directly from our API auth configuration.
09:33
Since it cannot discern between those types
09:36
and instead gives us a union,
09:38
the instances where we're just doing auth.user
09:40
aren't going to work where we need it
09:42
to literally be type of user, which we have right here,
09:46
hence the red squiggly.
09:47
So to fix that, all we need to do is specify
09:49
which guard it is that we actually want to use
09:51
in this instance, and then that will give us
09:53
the correct type for our user.
09:55
So if we do .use, that's how we can specify
09:58
which guard it is that we want to use.
10:00
In here, you'll see that we have as options, API, or web.
10:03
Here, we want to use the web guard.
10:05
And now those red squigglies go away
10:07
because our user is actually a type of user
10:10
as we see right here.
10:11
So we're now properly getting back just a type of user,
10:14
and we've dropped the type of organization
10:16
by specifying that we want to use the web guard specifically.
10:20
So let's give that a save.
10:20
We can close out our auth configuration now,
10:23
and let's bring back up that search panel
10:24
because we had one more occurrence of that.
10:27
We want to do the exact same thing here.
10:29
So .use and specify that that's using the web guard.
10:32
Everywhere else should be a-okay.
10:34
We can do a search real quick for auth.use,
10:37
and you can see in all of these other instances,
10:39
we're already using the web guard specifically.
10:41
So those are all going to be a-okay.
10:43
All right, jump back into our file explorer there.
10:46
So now that we have those instances fixed
10:47
and with that said, we're now good to move onward.
Join The Discussion! (0 Comments)
Please sign in or sign up for free to join in on the dicussion.
Be the first to Comment!