Client data segregation

Hi @v-appgami

The account_id is unique so can be used to segregate accounts data. However, if you want to store tokens your unique key should also contain the user_id as you can’t predict which user in an account will install your app.

Does that make sense?

Hi @basdebruin,

Thank you very much for the reply.

Right now, during this Monday marketplace validation phase, we are using this installation link for our app:
monday.com: Where Teams Get Work Done

Note that the client_id is on the install URL, and thus on every different instance that I install the app, the client_id in the client session token is the same.

I suppose that once published to the marketplace, this behaviour would be different then?

About storing tokens in the DB, we are actually just validating that we are receiving valid calls from the frontend by validating the Monday session token that we send through. I couldn’t find a reason yet to generate one token per user and store in the DB. Is there anything I’m not seeing here?

Hi @v-appgami

I am talking about an app (integration) where the code resides on a server. So, it is a server based app. To be able to run under the credentials of a user you need to get a token through the OAuth handshake. I don’t believe you can use the client_id as your token when your app is used in other accounts.

The marketplace link is the same for all users, it is just the installation link

Hi @basdebruin,

Right, I think we are talking about different things then. I don’t want to make requests to Monday from my backend on behalf of the user. What I need is to just validate that requests coming from my frontend are valid requests. For this, I am using the sessionToken obtained via the SDK monday.get method: GitHub - mondaycom/monday-sdk-js: Node.js and JavaScript SDK for developing over the monday.com platform

The flow is:

1. The frontend makes a request passing the sessionToken
2. The backend validates the sessionToken using the Client Secret of my app
3. If valid, I persist/read information from/to the database

Now, the problem is that the sessionToken seems to always have my app’s client_id instead of an ID that would represent uniquely the user’s Monday instance.

Does that makes sense?

hi @v-appgami

Yes, that makes sense. I do not have much experience with monday client-side apps. I only can show you how I do this in serverside apps when monday sends a request to my app

const { authorization } = req.headers;
const { accountId, userId, aud, exp, iat } = jwt.verify(authorization, envVars.signingSecret);

where my signing secret comes from envVars.signingSecret This gives me accesst to the accountId and the userId from the request header.

I see… well, there’s definitely something different between client-side apps and integrations then, because I can’t validate the token I get in the backend using the signingSecret but I need to use the clientSecret instead.

This is very strange, I don’t understand yet why the client_id in the sessionToken that I get from the frontend is my client ID instead of the user’s instance client ID 😦

Hi @v-appgami
client_id - is the unique public identifier of your app (this is why it is appearing in the installation url and in each request to your app).

For implementing multi tenancy you need to use account_id if you want to store information on the account level, or a combination of user_id + account_id if you want to store data on the user level.

Hi @VladMonday,

Thank you very much for your reply.

We want to store information on the account level, where each tenant would be one Monday instance (the account, not the user).

What you explained was my understanding as well. However, it seems not possible to store information tied to the account_id because this ID is always pointing our own instance (the one hosting the app installation). No matter what Monday instance is sending requests to our backend, the session token that we get from the SDK method monday.get. I would expect the client_id in this token to be the ID of the account where the request is coming from i.e. the client’s account, not ours.

Could this be a bug, or am I still confused with the concepts? Should I use a different token claim for identifying different customer accounts?

Thank you.

Hey Vlad,

I’m reading again your answer and now I understand. I confused client id with account id!

Now it’s all clear, I will use the account ID to segregate data and implement the multi tenant approach.

Thank you!