Call to Action for Apps Constructing URLs to GetTa...

hugheshilton · 04-15-2020 11:27 AM

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.

Marc_Dillon

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

hugheshilton

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.

Ami

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?

Grant_Stead

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

WillowMobileSys

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?

hugheshilton

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 https://www.appsheet.com/template/gettablefileurl 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.

WillowMobileSys

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?

hugheshilton

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 https://www.appsheet.com/template/gettablefileurl 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?

WillowMobileSys

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.

MultiTech

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

hugheshilton

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?

MultiTech

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

BUT…

Caching can get in the way when modifications are made. 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!

hugheshilton

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?

tecpme_casm

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

djmalaka

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?

Thanks

Steve

Please contact support@appsheet.com directly for help with this.

Gary_Ault1

Posting to an old thread, but it is realted.

I’m glad to hear the URL’s will be signed. Much more secure. Will the signed URL’s have a fixed lifetime or does the sign URL live on forever? If they expire, approximately how long will the signed URL work?

Gary_Ault1

I captured a URL for a file a week ago and it still works. It appears the signatures don’t have an expiration. That makes it a little more difficult to exploit, but having the URL(signature) expire would be far better from a security perspective.

On the up side, I guess you only have to generate the URL once and could store it so it works forever for anyone.

Fabian_Weller

This is a file URL that I captured on 19th January 2021 (it’s no 1 month old) and still working:

https://www.appsheet.com/get/?i=YXBwTmFtZT1LTVF1YWxpdHlHYXRlLTYyMjIyNCZ0YWJsZU5hbWU9QXJ0aWtlbCZmaWxlTmFtZT1BcnRpa2VsX0ltYWdlcyUyRjFhYWM3MDI1LkxhYmVsLjA4MDI0OC5qcGcmYXBwVmVyc2lvbj0xLjAwMTc0MCZzaWduYXR1cmU9ZmMxNGZjZjQ5OGExMDQwZWIyMzExODliMzIzYjdlZTMxNTI4NzkxOWRiYmE0NTdkOTNmMGUwYTU4NTUwZDAzNzBhOTAzMTM2OWZjOWM5ZTkyYjgwYjQxZmE2MmE4NWEz&w=600

dbaum

FYI for anyone else just getting here: @Fabian_Weller's test image remains available: https://www.appsheet.com/get/?i=YXBwTmFtZT1LTVF1YWxpdHlHYXRlLTYyMjIyNCZ0YWJsZU5hbWU9QXJ0aWtlbCZmaWxl....

@hugheshilton wrote:
As noted, the signed URLs do not currently expire

Cortex

Gary_Ault1

As of 4/9/212, I was able to open Fabian’s “test” image. The primary benefits of a signed URL is restricting access to the file to only those have been authorized. If the signed URL lives forever for anyone (authorized or not), that benefit isn’t achieved.

hugheshilton

Hi Gary,

As noted, the signed URLs do not currently expire although that may change in the future. The primary benefit of the signature on the URL actually has nothing to do with authorization. It is to prevent someone from hand-creating or modifying URLs to files within someone’s drive that they shouldn’t have access to. A URL to the gettablefileurl end point has a path to a file embedded in it. Without the signatures, a malicious user could change that path to a file that wasn’t even part of the app and get access. The signature prevents tampering with the URLs in this way.

Authorization is a different thing from the signatures. In order to require that only authorized users of an app have access to URLs to that app, the app owner has to enable the “Secure image access” option in the app. Obviously that option is not enabled for Fabian’s app or else you and I would not be able to see the test image URL that he posted. This is independent from the signature itself although the 2 mechanisms do work together to ensure the security of files within an app.

Kind regards,
Hughes

VGC_Innovation

Hi there, I stumbled upon this thread as I was working my way with images.

One concern about these signed urls though, I understand that Appsheet images show the following urls: "https://www.appsheet.com/get/?i=..." HOWEVER when I "open the image in a new tab", it then reveals a "https://lh3.googleusercontent.com/..." URL which makes it publicly available for anyone to see.

How can we prevent our users to do these steps?

Fabian_Weller

If you enable Secure Image Access , we do not cache the image in Cloudflare and image retrieval performance will suffer. You can enable Secure Image Access by going to Security >> Options in the app editor

mikebos

I started to see this error today 1/3/2024 😞 , how do I fix it in my case ( attached files ), I just removed Require Image and File URL Signing , but I don't see my QR generated images as before

Thanks

Call to Action for Apps Constructing URLs to GetTableFileUrl