Right way to exchange api keys with front end

Development
1

Hi there, I have Vue front end, and ModX as CMS and API, I already can expose a secured rest service, but so far, the use case it’s been a third party that accesses my services, but now I need my own front end (VueJs) managed inside ModX, to interact with my rest services on a secured way. (I use the modx Login Extra)

I’ve contemplated the following options

  1. Add a plugin to listen for OnWebLogin, generate the JWT token, then add it to the session, and just inject the token into my vue components as part my custom modx resources render process, then use it on the axios webservice calls.

  2. Add a step to the login, where the front generates a request to a secured resource for the token and stores it on the browser

  3. Use modx direct security (maybe I’m overcomplicating)? I mean, so far I’ve used this and exposed a new index.php with its own .htaccess file for third parties to access me, but can I just add that logic to a resource properly protected with ACLs and it will “just work”? this last one came to mind while I was typing this, but I’m wondering what should be the best practice with ModX

2

Why do you need an additional token when you already have the session-cookie?

1 Like
3

To use it along the jwt extra and have the rest services protected in the same fashion as I’ve been doing it, but I guess that you are suggesting is to validate directly using modx session?

Edit, just took a look at the thing from the database perspective and seems to be as simple as a query to the session table, my guess is if there’s already some API that gives this, and also, if the only difference between valid/invalid session is the amount of info on the data column?

4

With the MODX ACL system, MODX returns a 404 to anyone who is not authorized to see a page, so unless they’re able to log in, there’s really no way to bypass it to see secured pages.

How secure you need to make things depends somewhat on how sensitive the data is that you’re trying to protect.

1 Like
5

Thanks bob, what confuses me right now, is that to expose the rest endpoints I create classes that extends modRestController, how could achieve something similar from a standard modx resource?

6

Do users have to be logged in to MODX to reach the rest endpoints?

1 Like
7

Yes, they need to be logged as administrators, in order to use the front end that queries the rest services

8

You probably can use the function isAuthenticated to secure the REST endpoint.

public function verifyAuthentication() {
	if (!$this->modx->user->isAuthenticated('web')) {
	   return false;
	}
	return true;
}

Or maybe use $this->modx->user->hasSessionContext('web'). (I’m honestly not sure what the difference is.)

And maybe additionally check the user group $this->modx->user->isMember('MyGroup')

When you use the same endpoint for access with a JWT-token as well, then maybe check first, if a GET-parameter token exists and handle the authentication accordingly.

1 Like
9

About verifyAuthentication() …

This version in the modRestController class doesn’t seem very secure: :wink:

public function verifyAuthentication() {
     return true;
}

It’s an abstract class, so it can’t be instantiated directly, but the verifyAuthentication() method is not abstract, so it could be inherited as is. There may be a descendant class where that method actually does something, but I didn’t find one.

I think the method is there in case you want to add your own authentication to a descendant of the class. I’ve never seen it used in MODX.

So you may want to stick with hasSessionContext($context). The argument to hasSessionContext() can be ‘web’, ‘mgr’, or any other context key.

1 Like
10

Thanks a lot, after testing I realized I have 2 potentia escenarios, first is when everything is happening “inside” modx context, in this case @halftrainedharry works perfect, as there’s an existing session , and second is when its a PWA, where I only have the cookie generated in the beginning, I’ll follow @bobray advice and add just send the session id and validate against the session table as the modx->user is marked as anonymous, will test and update on what was the final implementation

11

Be careful how you “send the session id”. It’s safe to send it as a $_SESSION variable (in fact, it may already be there), but not in the $_POST or the URL.

1 Like