Scoping data fetching (relations)

[mihaa1]

Hello,
My setup uses authorizer to manage user auth while app user data is saved in the main db (the 1 remult sees - postgres), in the users table (created from User model).

For each request - I authenticate the request using a token - at this point - we are still in express-mw land. I then attach the user to the request obj so that getUser() can extract it (as specified in the tutorials).

I'm trying to get the user inside getUser() for all additional data like this:

getUser: async (req) => {
    const userData = await remult.repo(User)
      .find({ where: { email: req.user?.email } });
    if (userData) {
      return Promise.resolve({
        id: userData[0].id || '',
        email: userData[0].email || '',
        roles: [userData[0].role],
      });
    }
    return Promise.resolve(undefined);
}

But this causes some issues, specifically when combining with backendPrefilter() on entities. I'm guessing because of the async/await.
Example of backendFilter:

backendPrefilter: () => {
    return { organizationId: remult.user?.organizationId || '' };
  },

What/where would be the best place to extract to user data?

[mihaa1]

Update:
The problem is I'm accessing the model from getUser(), triggering backendFilter before I have everything backendFilter expects.
Now I'm left with the original question - where should I pull user data from my db so it is visible to all entities/controllers?
Assuming also I want the role so getUser() will block api access relying on it (such as role: 'admin')

[noam-honig]

Hi @mihaa1 ,

First of all - you can check the user roles anywhere using remult.isAllowed('admin') etc...
Here's an example from an app I'm writing:

https://github.com/noam-honig/trempim/blob/master/src/app/events/tasks.ts#L145-L165

As for storing data you have several options.

1. If you want that data to be shared with the frontend as well - you can extend the UserInfo object to include more information (phone etc...)
   https://github.com/noam-honig/trempim/blob/1e5f395bda16ed10cc9591f6788f982f8f08148b/src/app/common/UITools.ts#L54-L56

2. You can store on the server anything that you want, using remult.context and then you can access it anywhere in the server:
   https://github.com/noam-honig/trempim/blob/1e5f395bda16ed10cc9591f6788f982f8f08148b/src/server/server-session.ts#L8-L29

3. backendPrefilter is an async method, so you can fetch data there:

backendPrefilter: () =>{
const ids = (await repo(Something).find()).map(x=>x.id)
return {id:ids}
}

[mihaa1]

@noam-honig thanks. I'll have to check the context approach.
In the meantime - I added a raw sql query to get the user on each request in getUser()

const sql = await SqlDatabase.getDb();
    const command = sql.createCommand();
    const res = await command.execute(
      `
  			SELECT * FROM users
  			WHERE email='${req.user?.email}'
  		`
    );

This way I get the user's data (role, other stuff for scoping data), and don't trigger the User model entity methods.

[noam-honig]

Why? What is the advantage

…

On Sat, Oct 28, 2023 at 16:01 mihaa1 ***@***.***> wrote: @noam-honig <https://github.com/noam-honig> thanks. I'll have to check the context approach. In the meantime - I added a raw sql query to get the user on each request in getUser() const sql = await SqlDatabase.getDb(); const command = sql.createCommand(); const res = await command.execute( ` SELECT * FROM users WHERE email='${req.user?.email}' ` ); This way I get the user's data (role, other stuff for scoping data), and don't trigger the User model entity methods. — Reply to this email directly, view it on GitHub <#277 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD65PU6LKCFFMOB2WYLJVNLYBT6Z5AVCNFSM6AAAAAA6NQBJX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBTHAYDGOJUGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mihaa1]

@noam-honig if ur asking why I'm not using the context option - I still don't know how to yet (I need to move fast here on some development :)

[noam-honig]

You code is at risk of sql injection, with an invalid email.

Also - I'm not sure what you're getting in the result .

I think this can be solved by extending the UserInfo interface, at best - or by using repo to select the user as a less favorible option.

If you want, reach out to me tomorrow on discord and if I can, we can look at it together and I'll be happy to help