hi @oalbrecht

I would normally say: use a boardview.

But that is until I discovered this Account Settings View. Does anybody know what that is? Where will the user / admin add this view. From the name I guess it is outside the board, somewhere in the admin area?

For me this is a complete new view and I can’t find any information on it.

That’s a news for me too. It would be really useful to check General Caster usage.

Is there any documentation about it somewhere?

Hello there everyone,

We are working on the documentation on the new Account Settings View, which will be available very soon!

Sorry for the delay on it!

Cheers,

Matias

hi @Matias.Monday

The setup looks very straight forward to me . The only thing I was wondering is where does the view appear in the UI? Can you shine a light on that or is it too early?

Hello @basdebruin!

Yes! The user has to click on their profile picture (or initials), then on the admin section, then on the apps section and then on the three dots next to the app. In there, there is an option that says “Settings”. That is where this view will be shown.

Cheers,

Matias

@Matias.Monday Any ETA?

@Matias.Monday Do you know if there will be a way to authenticate users (e.g. JWT) on the settings page?

Also, it seems like this settings page is currently pretty hidden from users. It took me a good amount of searching to find it. Not sure if it’s on the roadmap, but it would be great if it were more obvious to users where to find their settings.

Thanks!

+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).

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

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 🙂

@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.

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

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

Thanks @anon29275264! I’ve added the request to the backlog 🙏

Hey @anon29275264,

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

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.

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?

@anon29275264 @dvdsmpsn