presigned urls for Bucketeer - heroku

Is there a way I can create pre signed urls with Bucketeer on Heroku ?
(i.e. so that an authenticated client web app can call my heroku server to get a presigned url which the webapp can then use to upload an image directly to (bypassing uploading image through my server app))

Related

Can Shopify-App Admin URLs be used as endpoints for Ajax requests?

I am developing an app for shopify. The app will provide pages and functionality for the Shopify Admin area, specifically using App Bridge.
The app bridge URLs look like this:
https://[shop].myshopify.com/admin/apps/[my-app]/[my-path]
When you visit this page it loads shopify header/footer/menu, also an IFrame pointing to [my-path] on my site, for example:
https://example.com/[my-path]
I would like to setup Ajax requests using the same system of URLs. for example I would use the endpoint as follows (I know this one doesn't exist, just an example):
https://[shop].myshopify.com/admin/apps/proxy/[my-app]/[my-path]
Then instead of rendering the IFrame with my URL, Shopify admin would proxy the request, forwarding it to:
https://example.com/[my-path]
Is this possible, or do I have to send the Ajax request directly to my own server? If the later, how is it recommended I do authorisation? Can the HMAC that came in the original request be forwarded to the AJAX request (seems that would be bad, but not sure exactly why), or use a session that I establish on the original request?
You setup an App Proxy in your App. You provide an endpoint in your App for the Proxy. Once this App is installed in a store, you can now call your App from the store itself, to the Proxy. Securely. That is the whole point of the App Proxy.

Azure AD authentication with CloudFront

I have a dynamic website hosted on Heroku and I am using Azure AD for authentication using oAuth 2.0.
I am trying to do Dynamic Whole site delivery using CloudFront.
During authentication, during the step when Azure AD server sends me the authorization code, I am getting a set-cookie in response headers when I run the authentication on Heroku (when I access the website using the Heroku URL)
But when I try to access the website using the CloudFront URL, I'm not getting the set-cookie in response header during the step when Azure AD server sends me the authorization code, hence my authentication logic is breaking.
Why is it so?

How to solve the risks in sharing an Amazon S3 pre-signed URL?

I am developing a Spring-boot REST API application. The following are the use cases
All REST API endpoints are secured using HTTPS.
All responses in this application are cached for 30 minutes based on the request.
One of my REST API response contains AWS S3 pre-signed url.
This REST API will be consumed by Mobile App
Issues
How to protect the AWS S3 pre-signed url from hackers who can snoop the request and response in mobile app.
Since I enforced the cache in my spring-boot application, I am not able to expire the pre-signed url before this cache timeout. The cached response containing the pre-signed url will be used until the cache times out. We are planning to make the cache timeout (say 5 minutes) smaller than the pre-signed url timeout (say 7 minutes)
Questions
How to protect AWS S3 pre-signed URL from hackers
How to handle this cache logic intelligently, because I don't want to re-generate this pre-signed URL often. Especially after evicting cache on list.
Is there any solution available to maintain this pre-signed url out of this spring-boot application. That is expecting something like other micro-service can handle this pre-signed url and will be used by mobile app directly.
Any response is kindly appreciated
Amazon recommends using their Server-Side Encryption with AWS KMS–Managed Keys (SSE-KMS). Here is a link to a Amazon blog series on how to accomplish using their aws-sdk for Java. This is a link to part 2 of 3 in the series.

Content delivery network

Is there any CDN service where we don't have to upload images manually,
It should get the image from original source (my site) site on first request and add it in storage for the next request. Note: My website in written in ASP.Net
Regards.
When setting up CDN on Windows Azure you configure it to point to a storage account. If you extend your application to save images to blob storage rather than local file system these images will be available via your CDN endpoint without any further work.
If I understand your question correctly, then the Azure CDN already does this (as does pretty much any CDN provider). You can configure the CDN to point to your website, and then when users access the CDN URL the CDN will fetch the content from your website and then cache it within the CDN storage. The next request from a user in that same CDN region will get the file directly from CDN without going to your website.
See the "Caching content from hosted services" section in this article.
If you store your image on your own origin server, you don't have to upload images manually to CDN. The CDN will get the image from your original server on first request and cache it in its edge server (not storage) for the next request.
If instead you store your image on CDN storage, you will then have to upload image to CDN storage so that it can be cached on CDN edge server upon first request.
All CDNs do the same for the above.

Is there a way to serve s3 files directly to the user, with a url that cant be shared?

I'm storing some files for a website on S3. Currently, when a user needs a file, I create a signed url (query string authentication) that expires and send that to their browser. However they can then share this url with others before the expiration.
What I want is some sort of authentication that ensures that the url will only work from the authenticated users browser.
I have implemented a way to do this by using my server as a relay between amazon and the user, but would prefer to point the users directly to amazon.
Is there a way to have a session cookie of some sort created in the users browser, and then have amazon expect that session cookie before serving files?
That's not possible with S3 alone, but CloudFront provides this feature. Take a look at this chapter in the documentation: Using a Signed URL to Serve Private Content.

Resources