In this lesson, let's explore one of the most powerful features of CKEditor, that is real-time collaboration. The ability for multiple users to work on the same document simultaneously is what truly sets CKEditor apart and makes it a genuine Google Docs alternative. Let's see it in action. Here, our editor is opened in two different windows, with one window in incognito mode.
This simulates two users working on different machines. Let's try to make some changes in both windows to see the collaboration features at work. First, I'll add a new paragraph in the first window over here. And look at that, it immediately appears in the second window.
You can even see my cursor position. Now, I'll switch to the second window and make some changes there. Notice how each user gets their own color for the cursor. and for selections as well.
If I hover over the cursor, I can even see the name of the user that that cursor belongs to. This makes it super easy to see who's working on what part of the document. Now, by default, CKEditor assigns random user identities, and that's exactly what we're seeing now. These development users come from the development-only token endpoint that we set up in an earlier lesson.
This endpoint is valid though only for 30 days. It's really only meant to get us up and running quickly. For a production application though, we need to set up our own server side token endpoint and to provide authentication and authorization for our real users. But what is a token endpoint?
Well, really it's just an API endpoint that returns a JSON web token for a logged in user. and includes specific data that CKEditor expects. This is exactly why we started the project with Nuxt. ts.
Next, we need to form the token payload. This is an object with certain properties specified by CKEditor. First is the AUD property. This is an environment ID that you can copy and paste from the CKEditor customer portal.
It ensures logical data separation between environments like development, staging, and production. Next is the subproperty, which IDs the user. This ID should be unique per user, of course, per environment. We're just hard coding the user ID for the sake of testing things out and the user property that will need to have an email, name, and avatar on there.
I've added my information just for the sake of convenience. Next, inside of the auth property, we need to set up roles and permissions that determine how a user can collaborate on a document. Each key in this object is the ID of a document that you want the user to collaborate on. For now, let's just hard code in a single document ID.
I'm using this placeholder ID because it's already set up like this inside of our editor component. We'll change this out for a dynamic ID later on, but this works for now. Oh, and yeah, this should be an object. Now we can specify what role the user assumes for this particular document.
There are three available roles. The reader role, commentator, and writer. These are pretty self-explanatory, but you can read more on this documentation page that I'm showing on the screen now inside of the official CKEditor docs. I've left a link to those in the description below.
We'll go with writer for our purposes, but of course, this value could be determined conditionally based on the real user data from your authentication system. If you want more fine grain control, you could instead provide a permissions array. Here, you could add specific capabilities like Document Read, Document Write, Comment Read, and Comment Write. You could even mix the permissions with the role.
Where this makes the most sense is if you want to give a user complete control even over other people's comments with the comment modify all permission. And that's it for configuring collaboration. The last properties needed on the token aren't unique to CK Editor. Let's add the JSON Web Token standard IAT and EXP properties.
IAT stands for Issued At, and should be the current timestamp in seconds. now for milliseconds, dividing by a thousand, and then just rounding down. EXP stands for Expires. It's a timestamp in seconds, at which the token is no longer valid.
That's done with the same math as above, but we'll add 60 times 60 just to make it an hour from now. If omitted, CK Editor Cloud Services will auto-expire the token after 24 hours, so you really could just leave this off if you wanted to. With the token now fully formed, we'll need to install the JSON Web Token library. That way, we have a way to sign it.
We can do that in the terminal with npm install JSON web token. Next, I'll import it at the top of the file, and then we can sign our token. The first argument is the token payload. Then the second is a secret key.
This is provided by CKEditor and can be found in the CKEditor customer portal under cloud environments, access credentials. I've already created one, but you can create one with this button here. Next, I'll set this as an environment variable. env.
Alternately, you could prefix it with NUX, but not the underscore public and set up another runtime config variable. But this is just a little faster. Lastly, let's configure the signature algorithm to be HS256. This is a very common algorithm for signing JWT tokens, and it works well in both production and local environments alike.
Now, that's it. All we have to do is return the signed token from the endpoint. view, let's modify the cloud services token URL so that it no longer speaks directly to the CKEditor cloud services, but instead to our custom endpoint. That should do it.
In the browser, I can see my own user avatar above the editor, and when I leave a comment, it's correctly attributed to me. Best of all, since we're doing all of the user authentication logic on the server side, there's no way for a user to impersonate somewhere else. In other words, we have both complete control and a system that we can trust entirely. In this lesson, let's explore one of the most powerful features of CKEditor, that is real-time collaboration.
The ability for multiple users to work on the same document simultaneously is what truly sets CKEditor apart and makes it a genuine Google Docs alternative. Let's see it in action. Here, our editor is opened in two different windows, with one window in incognito mode. This simulates two users working on different machines.
Let's try to make some changes in both windows to see the collaboration features at work. First, I'll add a new paragraph in the first window over here. And look at that, it immediately appears in the second window. You can even see my cursor position.
Now, I'll switch to the second window and make some changes there. Notice how each user gets their own color for the cursor. and for selections as well. If I hover over the cursor, I can even see the name of the user that that cursor belongs to.
This makes it super easy to see who's working on what part of the document. Now, by default, CKEditor assigns random user identities, and that's exactly what we're seeing now. These development users come from the development-only token endpoint that we set up in an earlier lesson. This endpoint is valid though only for 30 days.
It's really only meant to get us up and running quickly. For a production application though, we need to set up our own server side token endpoint and to provide authentication and authorization for our real users. But what is a token endpoint? Well, really it's just an API endpoint that returns a JSON web token for a logged in user.
and includes specific data that CKEditor expects. This is exactly why we started the project with Nuxt. ts. Next, we need to form the token payload.
This is an object with certain properties specified by CKEditor. First is the AUD property. This is an environment ID that you can copy and paste from the CKEditor customer portal. It ensures logical data separation between environments like development, staging, and production.
Next is the subproperty, which IDs the user. This ID should be unique per user, of course, per environment. We're just hard coding the user ID for the sake of testing things out and the user property that will need to have an email, name, and avatar on there. I've added my information just for the sake of convenience.
Next, inside of the auth property, we need to set up roles and permissions that determine how a user can collaborate on a document. Each key in this object is the ID of a document that you want the user to collaborate on. For now, let's just hard code in a single document ID. I'm using this placeholder ID because it's already set up like this inside of our editor component.
We'll change this out for a dynamic ID later on, but this works for now. Oh, and yeah, this should be an object. Now we can specify what role the user assumes for this particular document. There are three available roles.
The reader role, commentator, and writer. These are pretty self-explanatory, but you can read more on this documentation page that I'm showing on the screen now inside of the official CKEditor docs. I've left a link to those in the description below. We'll go with writer for our purposes, but of course, this value could be determined conditionally based on the real user data from your authentication system.
If you want more fine grain control, you could instead provide a permissions array. Here, you could add specific capabilities like Document Read, Document Write, Comment Read, and Comment Write. You could even mix the permissions with the role. Where this makes the most sense is if you want to give a user complete control even over other people's comments with the comment modify all permission.
And that's it for configuring collaboration. The last properties needed on the token aren't unique to CK Editor. Let's add the JSON Web Token standard IAT and EXP properties. IAT stands for Issued At, and should be the current timestamp in seconds.
now for milliseconds, dividing by a thousand, and then just rounding down. EXP stands for Expires. It's a timestamp in seconds, at which the token is no longer valid. That's done with the same math as above, but we'll add 60 times 60 just to make it an hour from now.
If omitted, CK Editor Cloud Services will auto-expire the token after 24 hours, so you really could just leave this off if you wanted to. With the token now fully formed, we'll need to install the JSON Web Token library. That way, we have a way to sign it. We can do that in the terminal with npm install JSON web token.
Next, I'll import it at the top of the file, and then we can sign our token. The first argument is the token payload. Then the second is a secret key. This is provided by CKEditor and can be found in the CKEditor customer portal under cloud environments, access credentials.
I've already created one, but you can create one with this button here. Next, I'll set this as an environment variable. env. Alternately, you could prefix it with NUX, but not the underscore public and set up another runtime config variable.
But this is just a little faster. Lastly, let's configure the signature algorithm to be HS256. This is a very common algorithm for signing JWT tokens, and it works well in both production and local environments alike. Now, that's it.
All we have to do is return the signed token from the endpoint. view, let's modify the cloud services token URL so that it no longer speaks directly to the CKEditor cloud services, but instead to our custom endpoint. That should do it. In the browser, I can see my own user avatar above the editor, and when I leave a comment, it's correctly attributed to me.
Best of all, since we're doing all of the user authentication logic on the server side, there's no way for a user to impersonate somewhere else. In other words, we have both complete control and a system that we can trust entirely.