I have a REST api that list me all files in a bucket. I show this list in a webview on a ios device.
It's not possible to make this file public.
So to my question, how can i access the files in my ios app?
My idea is, i create a read stream in my api that open a read stream to the file in the gcloud bucket.
Is there a better way to do this?
The canonical way to expose a private file is to used signed URLs. Basically, your iOS app would request access to a file from your app. If your app decides to grant this access, it generates a URL, signs it with a private key, and then provides that signed URL to the iOS app. The app then fetches the URL provided like any other URL, the body of which will be the object's contents.
Signed URLs have some nice security advantages. They can only be used for exactly one thing, and they're only valid for a few minutes (you can configure exactly how long they're valid).
The signing logic is a little tricky, but the gcloud libraries have functions to sign URLs for you.
Documentation is here: https://cloud.google.com/storage/docs/access-control/signed-urls
Related
My use case is that I want to stream a video which was uploaded to firebase storage.
My understanding is that when the video is first uploaded a firebaseStorageDownloadToken is created.
Then whenever in the client app I call getDownloadUrl a user gets access to the secret token and can technically share the url with others to watch or download.
I don't really need the long lived access or the videos to be shareable.
Isn't it then more secure to periodically refresh firebaseStorageDownloadTokens with a new value?
That would prevent the stolen urls from working.
And then if a user wants to watch same video again a new url through getDownloadUrl is obtained containing a new token.
Do you think it makes sense as a security measure?
What would happen if a firebaseStorageDownloadTokens is changed while I'm watching the video? Would the stream stop emitting?
While you can definitely revoke the default token, it isn't automatically shared with any users - so the chances of it being abused by them are pretty small. But: users that can upload through the Firebase SDK for Cloud Storage can also call getDownloadURL on the objects they upload and thus generate new tokens. If this is a significant concern for your use-case, you should probably not allow uploads through the Firebase SDK.
There (currently) is no way in the Firebase SDK to generate a URL that automatically expires. If you want that, consider using one of the Cloud SDKs for Cloud Storage, which have the option to generate so-called signed URLs that do precisely that.
after successfully uploading my app to appstore connect, i get this email from apple:
Dear Developer,
We identified one or more issues with a recent delivery for your app,
"Tamata" 2.0.0 (8). Please correct the following issues, then upload
again.
ITMS-90683: Missing Purpose String in Info.plist - Your app's code
references one or more APIs that access sensitive user data. The app's
Info.plist file should contain a NSPhotoLibraryUsageDescription key
with a user-facing purpose string explaining clearly and completely
why your app needs the data. Starting Spring 2019, all apps submitted
to the App Store that access user data are required to include a
purpose string. If you're using external libraries or SDKs, they may
reference APIs that require a purpose string. While your app might not
use these APIs, a purpose string is still required. You can contact
the developer of the library or SDK and request they release a version
of their code that doesn't contain the APIs. Learn more
(https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).
Best regards,
The App Store Team
i am not collecting any user data related to pictures/images, heres my info.plist:
whats the problem?
Probably one of the third-party library, that you have in you dependencies, has code that can fire request for photos. There are two ways to handle that:
Put NSPhotoLibraryUsageDescription to your info.plist, and have hope that some library not fire request for gallery. User won't see permission dialog, until request for photos wouldn't fire.
Find this library and change it for another lib, that doesn't have request for photos. To find out what lib can fire request, search phrase Gallery or Photo on every lib in .pub-cache directory and try to localize request for that permission. In AndroidStudio, on the Project view, you can navigate all libs in External Libraries tabs and perform search by ctrl+shift+F.
Is there a way to do this via the admin SDK? I am able to do this via the client SDK. I am baffled as to why admin SDK seems to lack many features that clients have. How do I get storage reference using a download URL in admin?
The Firebase Admin SDK for Storage is a fairly thin wrapper around the Google Cloud Storage SDK for that platform, mostly providing auto-initialization of the default bucket that Firebase uses. It does not expose any Firebase-specific functionality, such as mapping from download URLs back to a path in the bucket.
It's a valid request though, so you could file a feature request.
I have a React app running on google cloud run, with user authentications and permissions.
Now I would like to write documents for the app. The documents will be a static site holding at google cloud storage.
In the app, users with different permissions can access different routes of the app, and it would be great if the permissions work for documents too.
My untested solution is to control user access to the app routes, and certain route renders a page, that containing an <Iframe> which retrieves the documents and then display it.
My question is: is it possible to restrict access to the static site, to allow only access from the react app holding at cloud run?
Or is there any suggestion about access control of app documents?
"documents" were supposed to be html files converted from markdown files. They're documentations about what the app is and how to use the app.
And I don't want the part of the documentation about "admin configuration of the app" to be seen by users with regular authorization.
Holding the documentation as a static site is simpler. I can use gitbook (or other tools) to render the markdown file. Managing & rendering the styles of the markdown files in React would be a little painful.
I'm still working on my English. Sry about the confusions.
You can restrict the access to a static website in Cloud Storage by creating a redirect.html like it is posted in the second answer of this question. The complete medium post is located here.
This will work considering that the authentication from the static website will be separated from the Cloud Run authentication. As it can be seen here the permissions a user has will need to be defined for every object. There you can control if a certain document can be viewed by a specific user email.
If the serving of the Cloud Storage documents needs to be dependent on the Cloud Run authentication, then creating short-lifetime signed urls is an option. This is a python sample program to create signed urls and here is the description of what a signed url does.
I have an app with SwiftyDropbox that function correctly, but I need to insert email and password for Dropbox every time that I use the app.
The app it's only for my use, it's not a security problem if the app auto-login in my account.
I don't find examples or documentation to make an auto-login with SwiftyDropbox. It's possible?
While the Dropbox API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files, it is technically possible to connect to just one account. We generally don't recommend doing so, for various technical and security reasons, but those won't apply if you're the only user anyway.
So, there are two ways to go about this:
1) Implement the normal app authorization flow as documented, and log in and authorize the app once per app installation. The SwiftyDropbox SDK will store the resulting access token for you, which you can programmatically re-use after that point each time using authorizedClient.
2) Manually retrieve an access token for your account and hard code it in to the app, using the DropboxClient constructor shown here under "Initialize with manually retrieved auth token".