My app is remotely updated with image URLs from tons of different sources, most of these on HTTP servers. Now, these HTTP URLs won't download because of App Transport Security.
Apparently I have two options.
Allow all HTTP URLs: Bad practice, possible App Store rejection
Allow specific domains: Not possible because this would mean I can't remotely add images
How can I download the images without disabling App Transport Security?
What if you programmed your own web based API that downloads and stores said images - then you can retrieve them with a call to it. Secure your API with HTTPS. This also gives you more fine grained control in that you own the server you are querying instead of accessing someone else's.
Related
I have a nextjs application which uses the built in api, the front end website is fetching data from the api using vercel's SWR hook. There is no authentication on the website, and no plans to use any in the short term. How can I limit data fetching to the website only and protect the API from being accessed by other clients e.g. curl, postman?
I am using cors to whitelist the website domain, but this only limits access via the browser. At some point I plan to give access to the API to other specific third parties, therefore an API key would be an obvious approach, but if I use this on the front end data fetch, it will be visible to anyone using the website? Any ideas please what approach I can use? Thanks!
I'm building and app with firebase and expo in react native. The app has live streaming with Zoom Web SDK. In order to deliver a better experience to the end user, for example, the ability to send video faster and enable multiple video streams, which powers features like Gallery View and Virtual Backgrounds, we need to enable SharedArrayBuffer.
As of Chrome 92, SharedArrayBuffer is only available if your web page is Cross-Origin Isolated, or if your web page uses Credentialless headers.
We implemented the coi-serviceworker from https://github.com/gzuidhof/coi-serviceworker and the rules to implement this are:
Rules: 1. It must be in a separate file, you can't bundle it along with your app. 2. It can't be loaded from a CDN: it must be served from your own origin. 3. Your page will still need to be either served from HTTPS, or served from localhost.
THE PROBLEM:
When a implemented the coi-serviceworker in my code, all the files(images and videos) that comes from the firebase storage are not displaying anymore.
I think the error is because of the second rule, because we use Firebase Hosting to publish our app, but the Zoom Gallery View works.
Firebase Hosting uses an advanced global content delivery network (CDN) to make your website as fast as possible. Requested static content is automatically cached on the CDN. If you resume site content, Firebase Hoststatic will not automatically clear all content and CDN cache until the next request.
Someone faced the same issue? I appreciate any help!
In this age of *chat applications and various messaging software, I was wondering if there is already an official protocol (RFC) that would follow the following basic flow:
Client connects to Server for a new session
Client uploads an image (or video) with metadata information (size, resolution, format) to server
Server does some work (not part of the protocol)
Server replies with REJECT then client goes to 1.
Server replies with ACCEPT then client stops and gather the result as part of the reply from the server
I have a proprietary solution now that does the basic (supports basic formats) and as we know, the devil is in the details so I wonder if some existing protocol would cover the stream format and more unhappy paths I may have missed with this simple design.
I'm not aware of any protocol that can handle file probing for you ..
ffprobe is a good open source solution to do this but requires processing power and scale.
So this step must be done on server side, after the upload. You cannot trust the client for such information.
I suggest the cloud approach. Here, we're using Amazon Cloud.
Upload your file to AWS S3. You can use multi part upload for faster upload. No need to scale anything, AWS will do it for you.
Your clients just request a signed URL from your web server. The server return the URL and an ID for this new asset. Your clients upload to AWS S3 using the URL.
Once the upload is done, your client make a call to your server again to say: "I'm done with Asset ID blah". Your server knows the asset is now uploaded and can initiate transcoding, analysis, DB updates, etc.
We do this exact scenario in our project.
For transcoding at scale we use our own open source project: https://github.com/sportarchive/CloudTranscode
This is not an easy business, especially if you want to handle videos.
If you restrict yourself to pictures, then a lot can be done on the user side. You can create several versions of the image in JS, directly in the browser for example or in the mobile app, and upload them to your server. The load is much smaller and you may not need this decoupled architecture.
If you handle videos, you need a solid backend.
Hope this help
We are one of the Openstack cloud user and use Swift to store lots of files in cloud. And our users (the end-users) will access these files. If the files are public, then the end-users can directly visit the object URL in web or mobile applications. However, some of files are private. Each end-user can only access his own private files.
The end-user may have two methods to access his private files:
A. The end-user always sends requests to our server. And our server will get the files from Swift, and then send them to the user. In this
method, Our server can be regarded as a file proxy. We have the
authentication of Openstack, and the user has the authentication of
our server. We should maintain our own user system.
One problem of this method is the scalability. Because each request
will be sent to our server, then the server will be the bottleneck if
many files are uploading or downloading at the same time. The high
scalability feature of Swift can't be used if we don't have enough
servers. Actually we really don't need lots of servers except file
transferring.
B. The end-user directly sends requests to Swift. It may solve the huge file bandwidth problem. But he must have the authentication
method of Openstack. So we need thousands of Openstack accounts for
our users while we are only one of the user of Openstack! It seems
strange and is not feasible.
Are there any other methods to meet the requirement?
You could use your server to get the files (scenario A), but put that server "in the cloud". Then as access needs to scale up, you spin up additional servers under a load balancer. You, therefore, are distributing the load horizontally as needed.
An idea.
(Disclaimer: I am a Rackspace employee)
A third idea is to use swift's tempurl feature, when a client needs a file, you genenerate a signed url to the file, having checked checked if they are authorised, and the url they get enables them to download directly from swift,
so two problems are solved
1. User A can not get User B's files
2. Download is straight from swift, so your server does not become the bottleneck for downloads (only for authorization).
Does windows store has an API?
For example when you open the "store" app, there is a "top free" list that will show the top 100 most popular free apps. Is the list coming from an HTTP endpoint somewhere on the internet?
There is no official API for accessing content in the Windows Store. I'm sure that the content is being pulled in from the web via and HTTP or HTTPS endpoint but using an undocumented service like this would likely not be recommended. It also doesn't look like there is a protocol activation schema documented for launching the store. The closest thing I can find is the MarketplaceDetailTask in Windows Phone. http://msdn.microsoft.com/en-us/library/windowsphone/develop/microsoft.phone.tasks.marketplacedetailtask(v=vs.105).aspx
The only other supported way of launching the store would be by using links to apps which cause the store to open.