I am hosting a Flutter web app on Google Cloud Storage which works fine and is accessible via my sub domain app.mydomain.com. In general i'm pretty happy with Google Cloud Storage since it is easy to deploy and the costs of hosting are cheap.
Unfortunately, routing is a problem.
When i navigate via the app to the login page the address bar changes to app.mydomain.com/login and the login page is shown. But when i reload the page via the browser's reload button, I see the following XML
<Error>
<Code>NoSuchKey</Code>
<Message>The specified key does not exist.</Message>
</Error>
I assume this is because Google Cloud Storage wants to fetch the index.html file in the login folder. However, the bucket does not contain such a login folder.
Question:
How can I get this running?
Is it possible to deactivate the feature of fetching subfolders within a bucket to redirect the information of the address bar to my flutter app?
What would be a cheap alternative if there is no alternative?
Well, I figured out the problem.
If you pay close attention the the URL which i've posted in the question you might notice that the URL lacks the # character which is normally present. This is because i've had set setPathUrlStrategy() from the url_strategy package.
So instead of using app.mydomain.com/login my URL now looks like this app.mydomain.com/#/login which causes Google Cloud storage to correctly forward the URL to my application instead of trying to fetch a file or folder within the bucket.
Related
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'm working on a Google Drive interface for Emacs. The concept is that Emacs could provide a platform-agnostic way to load, modify and save text documents stored in Google Drive. I've registered my app and can authenticate with OAuth2 and get a file listing with the Docs List API, but when I try to execute an Insert with the Google Drive API, I see an error:
"The authenticated user has not installed the app with client id ..."
Reading further, it seems I need to publish my Emacs application in the Chrome Web Store to get access to the Drive API. That doesn't make sense to me...I noticed that there is a FUSE project in development for Google Drive, which suggests that native development is possible. When I skimmed the code, however, I didn't see a Chrome Web Store component to getting it working.
Am I trying to misuse the API, or is there an route to make this work that makes more sense?
EDIT:
According to Ali Afshar, of the Google Drive team, installation is no longer required to use this API. So what follows may no longer be relevant, but will be left for historical purposes.
So, first off the API does not support application development in the sense that we are both doing it, I wouldn't use the word native though. The good news is I have been doing some research and Google Drive is really just a rebranding of Google Docs. So the Google Docs API could be a good choice as well for the same purposes.
Anyway, here's the steps to solve the error: "The authenticated user has not installed the app with client id ..." Which is a 403 error, for the sake of this answer. These steps assume you have set up an app in the chrome web store as is required, and installed it. I am working on my local machine too, with my project: http://github.com/tom-dignan/gdrive-cli which I have gotten past this error, so I think you should keep plugging away at your emacs version, because I think we can make this work.
a. Open the Google APIs console.
b. Confirm you've already enabled the apis under "API Access" both the API and SDK for Google drive should be enabled. There you get your client secrets/api keys and such. I am almost positive you've done this already, so go ahead to C. (this is here for others who may have missed it)
c. In the left navigation bar, under "Drive SDK" you will need to do the following:
Add a "Support URL" (required)
Add at least a small 16x16 application icon (required)
Add "OAuth Client ID (Required)" under Drive Integration (I was just tinkering and this seems to be the key field.)
Add "Open URL (Required) URL to open for your app from the google drive UI."
Check off "Multiple File Support"
Add some MIME types and file extensions, "text/plain", and txt for example
Add the the auth scopes:
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
Don't bother trying to add the auth scopes for Google Docs here, because it won't work. Google does not want us to use it that way because files that drive apps create should be private to that app. Integration with Google Docs will have to be separate.
Now I know you must be thinking "why do I have to add some of these..." It's because the form makes them required fields. In mine, I put a couple URLs that point to static HTML pages.
Once you've done the above, clean up your state and reinstall your chrome app. Then try your code again, and it should stop giving you a 403.
I am running into a difficulty with the picker api for users who have installed our Chrome Web Store app, but who have not yet enabled drive. For users in this state, it is possible to save new files using the files/insert api, which returns a successful response, but these files do not show up in picker. Once the user enables drive, all the files they have previously saved begin showing up in picker.
Is this behavior intended? If so, what is the best way to determine if a user has drive enabled, so that we can prompt users to enable drive instead of making it look like we're not saving their documents?
Currently, the picker and the API will only work if the user has installed your Drive application ont he Chrome webs Store.
We understand the pain involved for developers and we are looking to relax this restriction.
In the mean time there is a way to check if the user has installed the Drive app, for that you need an OAuth 2.0 access token (so your user will need to have gone through the OAuth flow and authorized you to access his Drive data). Then you can simply try to read a file with a bogus ID (lets say ID "000" or "abcdefghijklmnopqrstuvw"). If the API returns the error "403: The authenticated user has not installed the app with client id {clientId}", that means that he has not installed the app yet and that you should hide Drive functionnalities and probably show him something that say "To take advantage of our latest Google Drive integration/features, we recommend that you install our Drive App link to Chrome Web Store listing".
If the user has your Drive app installed you will get a "404: File not found: {fileId}" error on this request.
First it is odd that the picker is not showing files for your non-drive enabled user.
So I just tested the picker with a non-drive account and everything worked as expected... For instance you can try with the Balsamiq Drive app https://chrome.google.com/webstore/detail/pplbmgaodhjmbklkgkgmlghaekcfhhkk They are using the picker in Mockup > Open...
After installing you have to go to https://balsamiqgdrive.appspot.com
I created a mockup first and saved it. It appeard in Docs. Then I tried the picker in Balsamiq and I could see it.
I have made a facebook fan-gate app. I was wondering if anyone had any success using google cloud storage instead of their own server storage.
I tried amazon cloud storage but apparently that will not work for a reason that is out of my realm of expertise.
I have tried a few times but couldn't get it to work.
dont know what to use for the
Page URL
Secure Page URL
Tab URL
Secure Tab URL
or APP domain
We use Amazon S3 for storing files for an facebook fan page app.
You can see it here https://www.facebook.com/Trustpilot?sk=app_264324680252883 and the html file shown in the iframe is actually just https://s3-eu-west-1.amazonaws.com/s.trustpilot.com/facebook/163506/70729414688.html.
Facebook hide this if you look at the source code as they use an proxy. I thing they do that for preventing people to have tracking software such as google analytics.