Hey folks! I have what I hope will be a quick question.
Previously I’ve been really focused on getting dynamic PDF links to display within the Tulip Player. I’ve moved past the “within the Tulip Player” part, but I’m stuck on using dynamic links to view files.
As the GIF shows, when I click my purple button, it gives me an error in a new chrome tab. But when I click the File information in the Table record, the pdf displays perfectly.
If you would like some clarification please don’t hesitate to ask! My operators can definitely just click the table record if that’s easiest, but I want to learn how to work with files (or file URLs) in triggers Thanks!
This is just off the top of my head, so take it with a grain of salt these files are retrieved securely from S3, so when you are using the table widget it is ‘signing’ them for you automatically. To accomplish the same thing from a button you would want to use the API (Tulip calls it a Bot)
Hi @TechnicallyKatie, following up here from office hours. Can you remind me: were you getting this access denied errors on files you recently uploaded into a table?
Yes, I had uploaded about ten files and tried opening them up within half an hour. All of them threw me this error. That said, they did automatically pull up a browser window, which IS what I want it to do! It’s just the thing it displays (the error message) that I want to change.
I’ll need the files to be viewable well after I upload them too. I have a vague sense that the URL remains signed for a period of time and then it changes, but maybe I dreamt that last night lol.
@John Could this be part of my problem? I don’t know what level of authentication I require to access the documents I uploaded. The “Tulip API” environment I created looks like it only has basic authentication.
Hey all! Sorry for my delay, noting some things here -
@mellerbeck is totally correct in that the S3 URLs that you’re trying to access in the browser are, in fact, signed. Tulip authenticates links opened within the app (i.e. your purple button), but the “open link” trigger instead directs a new window to attempt to access the link. That new window doesn’t have a way of first signing or authenticating to Amazon that the requester is, in fact, still Tulip.
…yet.
After talking with the engineering team, we’ve agreed this would be a great Quality of Life improvement and is definitely worth some work. The ability for the “Open Link” Trigger Function to automatically identify a Tulip S3 link and pre-sign it before opening has been put on our roadmap and is being worked on. This will likely be completed and out in platform release r249, and I’ll loop back here with more info.
In the meantime, the process listed up here to request a signed link would definitely get the job done.
Thanks, @TechnicallyKatie , for this feedback and helping us make the product better!
@k.ober This is awesome news for me! It seems like such a small difference, but it would really improve my app for the operators. Thank you so much for the update.
@TechnicallyKatie
Just checking in here - this feature just passed QA, and should be in for platform version r250! Look for this to hit your instance likely next week. Thanks!
Thank you for the update! I was definitely working on other projects on the office, so hearing that this has been resolved is a great update. Please pass on my thanks to the team.
Thanks!