Where to put app settings and how to authenticate on settings page?

+1 on this.
@Matias.Monday While waiting for the documentation, can you tell us how to use the sessionToken?

I was able to figure out how to authenticate on the settings page. It works the same way as it does for board views and uses seamless authentication (more info here: Choosing an authentication method).

1 Like

Thank you, @oalbrecht
Anyone knows if there’s a way to use the sessionToken without the Monday SDK?

Here is the current documentation! @rob @basdebruin @oalbrecht

1 Like

Hello @rob!

If you want to get a token to be able to use monday’s API to get information from the account/user, you will need to use the SDK. There is no token in the payload.

You could also use OAuth but at this screen it is not recommended at this screen.

Cheers,
Matias

We have moved the documentation, so here is the updated link :slight_smile:

2 Likes

@oalbrecht @basdebruin Did you find a way to seamlessly authenticate to the API in the app settings view?
As far as I can see the sessionToken passed in GET to the page contains only basic information:

{
    "client_id": "abc",
    "user_id": 123,
    "account_id": 456,
    "slug": "omnidea-dev",
    "app_id": 789,
    "app_version_id": 987,
    "install_id": -2,
    "is_admin": true,
    "is_view_only": false,
    "is_guest": false,
    "user_kind": "admin"
  }

The only solutions suggested by monday is to perform a OAuth2 process, which requires the user to accept the permissions request. Not so handy.

@rob I used the following code to get the session token:

let monday = window.mondaySdk();
monday.get("sessionToken").then(res => {
     console.log('Your token:', res.data);
});

I verified this JWT using the monday.com client secret on my server. I just needed the account id for my use case, which it contained, so that was sufficient.

Thank you, @oalbrecht, but the sessionToken passed via GET to the app settings view cannot be used to authenticate unfortunately.

@rachelatmonday

Would you be able to document the contents/structure of the JWT payload from the SDK? it seems the payload is undocumented. Just trying to make it easier for anyone needing to look it up.

1 Like

Meantime, drop the JWT token into https://jwt.io to inspect the payload :wink:

1 Like

Well yes, my point was it’s not in the documentation that I can find.

2 Likes

Thanks @codyfrisch! I’ve added the request to the backlog :pray:

1 Like

Hey @codyfrisch,

It has been a while, but I just wanted to follow up on this request! I heard back from the team who said this unfortunately isn’t possible as the payload body is not a public API.

Best,
Rachel

1 Like

Yet… we’re required to use the payload in the session token JWT within our backend to get the account ID & user ID to verify the JWT is actually from the account & user the request is being made for! Otherwise we’re permitting request forging from one account to another if we use the session token for authentication but don’t utilize data in the payload of the JWTs to match the JWT is actually valid for the request being made!

I’m calling BS on that “its not public” if we have to use the data in it to properly secure customer data.

1 Like

If the JWT is passed around in http requests, of course it’s public. You only have to find one to see what’s in it.

Properly documenting what’s valid within the JWT is the next step.

Of course its public since we can access it print its contents to console, and access it through a public API.

Since there is an expectation we use the contents of the JWT for something (its not just a random string signed with our client secret) then the contents are part of a public API by definition. If there was never a reason to use the contents of it, i could see it being called “private” (in the sense it could change at any time without warning). But thats not the case.

Essentially we can’t guarantee to support the same structure. Is there specific data that you need from the token?

@codyfrisch @dvdsmpsn

1 Like

The account_id, user_id, app_id - everything you’d need to use it for authenticating a requests… here is why.

The token is used for authentication between a front end app and a backend for the app - this is its purpose per the documentation.

Since this thread started out being about app settings apps, if the app has a backend where settings need to be set (entirely conceivable) then anything we send to the backend must include the account_id at a bare minimum just to work. We also need to send the token to authenticate. The token contains the account_id, so its a great way to send the account_id. Even if we sent the account ID in the request body, we’d need to verify the token is for the same account because otherwise someone could from their own account manipulate requests and access other other accounts! Thats why the token contains the account_id, to prevent that!

Lastly we must validate the payload if we use it, because we are required to do so per the marketplace approval process - and that is why we need its structure, types, etc. defined, so we can adhere to the security requirements monday.com has placed on us.

Hoping this will help :thinking:

1 Like