Call to Action for Apps Constructing URLs to GetTableFileUrl

We recently made a security enhancement wherein image and file type columns have signed URLs generated for them. This enhancement prevents an app user from changing the table name or file name parameters in order to access app files that they should not. In the near future, we are going to start requiring calls to the gettablefileurl and getappfileurl endpoints to have valid signatures.

What does this mean for you? If you have an app where you are manually constructing a link to a gettablefileurl or getappfileurl endpoint, that link will stop working very soon UNLESS you edit your app by going to Security -> Options and unchecking the toggle for “Require Image and File URL Signing.” By unchecking this option, you should understand that you are making your app files less secure. An app user could potentially modify the URL in order to see any file in the app that they could guess the file name for. If the Secure Image access and/or Secure PDF access settings are disabled for the app, this means potentially anyone can do this. It is best to leave the option checked if possible.

A note on XY column background images. Since a full URL is now being generated for images and passed back to the client, you no longer need to construct a URL for the background image of an XY column if you want to use an app image. You can now reference or de-reference an image column for the background image and the map should work correctly.


So will this signed URL be publicly accessible?
And how do we get this URL, for example in a workflow template?

The accessibility of the URLs does not change. If Secure Image Access is turned on for the app (or Secure PDF Access for files), then the images (or files) are only accessible to users of the app who have logged in. If Secure Image or PDF Access is not turned on, then the URLs are accessible publicly. This is the way URLs to app files currently work and is not changing.

Workflow templates also do not change. If you reference an image, then that image will be part of the generated PDF (unless you create a format rule to format it as text in which case the URL will be in the PDF instead). If you reference a file, then a link to that file will be part of the PDF. None of that changes except that the URLs will have a signature to keep them from being tampered with.

1 Like

Just so i understand. I now have an XY column type for which i have generated a URL for the image. This will no longer work? And from now i can simply load an image to my app and use it for the XY column?

1 Like

Yes. You can just call the image column.
We just retooled our app

I don’t think I am affected by this which maybe is why I am having trouble understanding this original post.

In the excerpt above it seems to say that I must uncheck the toggle for my app to continue working but then later says “It is best to leave the option checked…”. Can you elaborate on this?

tldr; If you didn’t understand the original post then most likely this will not affect you and there is nothing you need to do.

This only affects people who are manually constructing links to app files (such as images or PDFs) by creating URLs to the endpoint. People usually do that using the CONCATENATE and ENCODEURL functions in AppSheet or sometimes in Google Sheets or Excel outside of AppSheet. If what I just wrote sounds like some weird jargon you don’t understand, then most likely you are unaffected and no action is required. You can leave the security setting checked and your apps should continue to function correctly.

Remember that there are others in the community. My question was for everyone’s benefit. I think me saying I am unaffected distracted you from answering it.

I was politely trying to point out that there seems to be a contradiction in the post.

Why do you say that the app might stop working UNLESS you “uncheck” the toggle but then later say “It is best to leave the option checked”? This seems contradictory. Is there some value in unchecking it and then checking it again? Is there at typo?

1 Like

What I said trying to say was that the link will stop working, not the app. I’m sorry if that was unclear. A manually constructed link to will stop working without a signature unless you uncheck that security setting. By “manually constructed” I mean you are creating the link text yourself, usually by using the CONCATENATE and ENCODEURL functions within AppSheet or else you are creating the link outside AppSheet in order to display your app images in, for example, Google Sheets.

To clarify on the advice to keep the setting checked: the signatures in the URLs add an extra layer of security. If you are NOT manually constructing those URLs to gettablefileurl, then you should leave the security setting checked since it makes your app files more secure. The only reason you need to uncheck the setting is if you have a business need to construct those URLs without a signature. Does that make more sense?

I should have used the word “link” instead of “app” in my question. What a difference a word makes, huh?

Yes, that seems more clear. The rationale between the choice of “checking” or “unchecking” the option seemed to be, in my mind, blending together. But I understand now what the choices are and the impact of that choice.

I think I may be affected after all and need to investigate. I’ll post any concerns in a separate thread.

How can we configure things so we can continue to use the endpoints you mentioned above, but include the valid signature?

There is no way for you to generate a valid signature if you are manually constructing URLs with CONCATENATE. In that case, you’ll have to turn off the signature requirement security option. If you aren’t manually constructing URLs, then URLs for your images and files will be constructed for your apps automatically and there’s nothing you need to do for that to happen. Does that make sense?

1 Like

Thank you @hugheshilton, your explanation does make sense; and I’ll add that the system generated actions to open these links work.


Caching can get in the way when modifications are made. :frowning: The manual concatenate of the file URL was nice because it would actually open the file URL (actually re-downloading the file again); but using the system generated action causes the app to recall the cached file.

Things work; but if I have a report generator that creates PDFs and I’m trying to incorporate this into a client’s app - if they see a miss-spelling or something, go and make the change, re-generate/update the PDF, then check it again (only to see the originally cached PDF, and NOT seeing their change)… this is a problem. The file is actually updated (if you check the actual file in the cloud), we just can’t get to it until a certain amount of time has elapsed.

And trying to say to a client, “Oh… well… you just have to wait 30 minutes or so for the update to show.”

Anyways, thanks for the answer! :nerd_face: :+1:


Hmmm, I believe if you enable “Secure PDF access” for the app in Security -> Options then the PDF links generated should not go through CloudFlare and no caching should occur. Does that work for you in this scenario?

1 Like

I updated the security option and everything went back to normal.
Thanks for the feature it will be useful in my medical app.


Hi, I have this affecting my app. I’ve used Flaticon site’s certain vectors as buttons for my app and since 2 days back my app stopped showing these links. So I did go an uncheck the “Require Image and File URL Signing”, but the problem still persists and the images are not being displayed on my app. Anything I could do for this other than manually creating a folder inside my google drive and add the vectors and then providing the link via AppSheet?


1 Like

Please contact directly for help with this.