Storage not accessible from view

Caution: speculation ahead…

If I remember correctly, the global storage that you can use on the client-side is also accessible via monday code’s storage API. But let me double check and get back to you…

Hey @danlester – yes you can!

Using global storage in the client

You can use our “global storage” in the client with the following methods (in the monday-sdk-js package) -

• monday.storage.getItem(key)
• monday.storage.setItem(key, value)
• monday.storage.deleteItem(key)

Docs here.

Accessing storage on the server

If you use global storage in the client, your backend can access this data using the apps-sdk package (built for monday code).

You initalize it like this:

import { Storage } from '@mondaycom/apps-sdk';
const storage = new Storage('<ACCESS_TOKEN>');

And use it like this:

const value = await storage.get(key, { shared: true });

The shared option controls if a given record can be accessed in the client (or not). This can only be controlled from the backend. AKA the frontend can’t choose to store a value only for the client-side, but the backend can.

Let me know if that makes sense!

Thank you for setting this out. The problem is that it’s not entirely clear what can be used as ACCESS_TOKEN.

The client storage works fine for me (the session is implicit here anyway).

In the backend, we only have the sessionToken which was obtained via monday.get('sessionToken') when the Board View called fetch to send a request to the backend.

In an automation (workflow action) handler, we only have shortLivedToken passed by Monday when it called our endpoint.

In both scenarios, the storage API doesn’t seem to work - I just get “You need to log in or sign up before continuing” in the logs.

It doesn’t make sense for the app to obtain an OAuth2 token for the user (and in any case, I’d want to store this in Storage!). The point is that we can store this data fine in our own database, but it doesn’t seem to work using Storage with the usual tokens that are available to my app.

Maybe there’s another way to create a token that I’m missing.

Good questions. Let me lay out some recommendations for each scenario:

Client-side API calls or accessing storage – Use the SDK methods for seamless/implicit authentication.

Backend of fullstack app - The sessionToken cannot be used as an API key, it should only be used to authenticate between your frontend and backend. You need to use OAuth in this case. You can store the tokens in our Secure Storage.

Automation/workflow block – you can use the shortLivedToken for this. I have never seen that error before, to be honest…

Side note – why doesn’t it make sense to need an OAuth token on your backend? I’m not disagreeing, just want to understand what other options you are envisioning.

OK this helps, and I’ve made some progress, but still have some concerns about whether there are compromises if we’re trying to build an app entirely hosted within Monday Code. So I really appreciate your feedback, as that would be a worthy goal!

First of all, in the Automation/workflow block, this was denied because I only had board:write/read scopes set in the app. I’ve added user:write and user:read in the OAuth panel of the app settings, and this now works. (It would be great to indicate those scopes are required for storage, in the docs.)

Backend of fullstack app - this is still an issue really. I certainly could add a redirect URL to the workflow, and redirect the user via my own OAuth flow (which wouldn’t need any input from the user - it would just flash through the redirects, storing the access token on the way).

But this seems like an unnecessary step, creating an unnecessary token, essentially just to enable database functionality within Monday Code. To reiterate, I do not need the OAuth token here other than to make use of Storage in place of a database - and a database works fine, and securely, on my own infrastructure.

This encourages some undesirable workarounds:

• Setting storage values on the client side, where they are susceptible to user interference.
• Using Secure Storage throughout, and having to explicitly index keys with account ids, rather than segregated by account as is intended using regular Storage.
• Using a database on separate infrastructure, with communications running over the public internet.

If your strategy is for apps hosted on Code to be more secure by design then I do think something is missing here (or maybe I’m missing something…). Thanks again.

Thank you for that writeup! Now I understand what you’re saying.

The global storage methods are actually a wrapper for our own storage REST API behind the scenes. You need the OAuth token to authenticate to it. We’re in the process of releasing & documenting this as a standalone API but it’s still a few weeks out.

Even though that’s the technical reason, I think your point still stands:

• it’s not clear that you are using another API behind the scenes, and
• you want to be call the API without auth as long as you’re using the trusted monday code environment

Makes total sense. I’ll push this with our product team.

In the meantime, do you mind if I recategorize this as a feature request?

Yes, sure, this can be a feature request. Thank you.

It’s not entirely clear that being within the Monday Code environment is enough. It could make sense, e.g. for the sessionToken to be required, to ensure the storage request is tied to a particular account.

But that’s perhaps a product decision for your team to make…

Agree, we’ll need to figure out how to 1) authenticate appropriately and 2) flag which account’s data you’re trying to access.

But either way, now you know why you need an OAuth token to access the storage! I’ll take it from here 🙂