Where to run the (node.js) webservices

Hi @basdebruin
It’s a very good question.
We are planning in our long term roadmap to add more and more capabilities, which will make Apps developer life easier (low-code approach), which also includes the ability to host your code (in more of the serverless approach).
But most probably it will happen not very soon, so for now you will need to host your service/mongo on VPS or in some cloud (AWS/Azure/GCP/etc.)

Hi @VladMonday

Many thanks. At this moment my integration is running on a VPS (public IP) with React/node and a Letsencrypt SSL. Currently adding MongoDB to the mix. Do I make a correct assumption that I need to store the token for each accountid / userid / boardid combination? After some testing it looks like the some scope and userid gets a different OAuth token on a different board. Is that correct?

Hi!
Each OAuth token is coupled to a specific monday.com user and account.
Our tokens are not coupled to any specific boards, in a way that if you’ve asked for the boards:read scope, then the token you’ll get will have access to all of the boards that the user is permitted to see.

Each time you direct a user to perform an OAuth authorization process, you’ll always get a new token, regardless of the parameters that you send.
Note that you can skip the OAuth process if you already know that you have a token stored for the user in your database. You can do it by using the accountId and userId parameters that are stored in the JWT of the authorization request, and deciding whether to send the user to the OAuth process, or immediately redirect them to the backToUrl (which will send them straight to configure the new automation).

Hi @moshik

Thank you for your clear answer. In my opinion there is a potential issue with the fact that the received token is valid for all boards the user has access to. If I have Integration-1 that need read access the user authorizes this read access. If another integration (Integration-2) needs write access the user may authorize that request (for write) without understanding that he is now also authorizing write access to the board that uses Integration-1.

Has this been discussed in the development team and do you think it is the correct design?

Hi @moshik, @VladMonday, @dipro

Sorry for the wide distribution 🙂. I am considering to make the boardId part of the database where I store tokens. So, something like accountId / userId / boardId / token. The reason for this is that you might have different scopes for different Integrations added to different boards. I do this by adding the boardId to the state in a way it can be easily retrieved when receiving the state back in the callback.

Just want to know your thoughts on this. Do you consider this to be a good practice?

Hi, We did discuss internally having board level tokens in the future. I agree that right now it can cause issues for users that don’t one a certain app to have access to all of their boards.
We definitely plan to expand our API scopes system in the future.

Regarding your question, it makes sense to have it this way if your app has multiple integration features, with each requesting different scopes.
It gives me another idea for the future - maybe we can also send more ids in the authorization JWT - such as identifiers for apps and recipes to let developers further customize their requested scopes per use case.
If we’ll show the app and recipe ids in the developers section then you’ll be able to reference them in your code and request different scopes according to this information.

What do you think?

I think this would be a very good functionality for future versions. Maybe you can also consider to send additional ids in the response to the post to authRequest. To maintain the relationship between the code used in the authRequest and the ids I currently kind of mis-use the state and set it to accountId–userId–boardId to be split later in the callback function.

More in general I would say that the developer always start the OAuth cycle, even when the token is already known (I delete it from the database if known). With this - in case you need to extend / limit the scope - you can instruct your users to de-install and install the integration from the board.

Hop I am not confusing my friends 🙂

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.