I am using Google Cloud Storage for one of my project requirement, that also required to use Signed URL, and when I reached google documentation here https://cloud.google.com/storage/docs/access-control/signed-urls
It now talks about V4 (version) to use for signed URL, another place it also says like it's in BETA Mode? Now I am sort of on my beginner step to get SIGNED URL for the objects stored in GCS, but its documentation confused me.
If I follow V2 documentation refer here: https://cloud.google.com/storage/docs/access-control/signed-urls-v2 then it documentation say Important: This page covers legacy material related to the V2 signing process. It is recommended that users work with the V4 signing process instead.
If I follow V4 documentation then refer here: https://cloud.google.com/storage/docs/access-control/signing-urls-manually then it says This feature is in a pre-release state and might change or have limited support.
Sure I will reach to GCS support as well, but still thought to ask from the community,
A. What is the difference between V4 and V2
B. On both cases Google Cloud Storage's Documentation contradicting the SIGNED URL functioning
It seems that you have received an answer in the Public Issue Tracker from GCP of your question.
In addition to the answer posted:
A. What is the difference between V4 and V2
The difference is mostly at implementation level, how the signature is constructed. Also, in V4 you cannot create signed urls whose expiration date (X-Goog-Expires) goes beyond 7 days, whereas this can be set for years using V2. Something else is that V4 is now more suitable to carry out GCS-AWS operations, so if you need this option, this beta would be your only option for it. As this is the main purpose for V4, more details about the signature are left to the AWS documentation.
B. On both cases, Google Cloud Storage's Documentation contradicting the SIGNED URL functioning.
In V2 Doc explicitly says: "Important: This page covers legacy material related to the V2 signing process. It is recommended that users work with the V4 signing process instead.". Even when the V4 is in Beta now (Oct 2, 2019) this should not be taken as something contradicting. It is a recommendation to use the V4.
In conclusion, you can try with the V4 since there is even a way to create the signedURL from the Gsutil
Related
I am currently on Google Analytics API v3. Since Google Analytics 4 (GA4) just came out, I am looking into upgrading to API v4, however, I have noticed that the API v4 does not include GA4 properties and the API that handles GA4 properties is currently in alpha (I believe it's Data Reporting v1).
Will it be more work for me to update my existing application to API v4 from v3, and then when the beta or general release for the Data Reporting v1 arrives, upgrade then, or should I wait to upgrade from API v3 to
I am under the impression that v4 doesn't have the ability to pull GA4 properties, however, since it runs on completely new endpoints and Google has mentioned all future development will be on v4 then I should just move to it so its less work when the newest API comes out with those features. Does that sound right?
Marshall,
You are correct, the Google Analytics Reporting API V4 cannot access GA4 properties, you need to use the Google Analytics Data API V1 in order to do this. New features development will only be done in the Data API. Both APIs are conceptually similar, but the decision mostly depends on which type of properties you need to access.
As a side note, I believe the Data API is slated to graduate to Beta in a matter of weeks.
Thanks,
Ilya
The Google Analytics Team
I am an intern and currently doing automation on a software. What I need to do is to automate the process of creating, and starting an application in the cloud foundry using Rest API (rest-assured). I can't start an app because to start it I need to upload bits. I searched for weeks and still cannot find how to do it. I can only use V2 of the Cloud Foundry API, because when I create an app using the V3 API it doesn't show in the dashboard. I don't know why so we decided to just leave it and use V2 instead.
My question is: Is there any way to create, and deploy/start an app using only Rest API with the V2 API of the Cloud Foundry API? If there is a way to do this by using V3 API, I'm willing to search for the solution to solve the issue.
Thank you very much.
I think others commented on your question to use the cf command line, but if you want to use whats behind the scenes of cf then you can refer to the REST API Docs. At the top the page there is a API version selector (I linked 2.9.0 since you mentioned V2).
More specifically, to create an app you can use the Create App Endpoint; then to upload the bits, you can use Upload Bits Endpoint.
I hope this helps. Definitely check out the main docs, there are tons of endpoints that might be useful. Good luck on your internship!
EDIT: Just in case you need the CF API URL its https://api.ng.bluemix.net
If you want to see how the cli uses the rest api behind the scenes you can temporarily set the environment variable BLUEMIX_TRACE with the command line EXPORT BLUEMIX_TRACE=TRUE.
Then you can try doing cf push or cf start, cf stop, etc, and you will see the http requests the CLI uses. This has helped me a lot versus digging through the CF documentation :). Hope it helps!
I solved it by combining V3 API with V2 API. I understand the upload bits in V3 API. I use link[1] mainly to start the app. I think you can't create a route in V3 API because I don't see any endpoint for that, so I use V2 API instead to create and assign. I also use V2 API to create my app because of what I stated in my question. Thanks for answering the question because without the answers given by good people here I can find the best way to solve this.
[1] Create an App using V3 : https://github.com/cloudfoundry/cloud_controller_ng/wiki/How-to-Create-an-App-Using-V3-of-the-CC-API
[2] V2 API doc : https://apidocs.cloudfoundry.org/3.1.0/routes/list_all_apps_for_the_route.html .
[3] V3 API doc : http://v3-apidocs.cloudfoundry.org/version/release-candidate/index.html#get-assigned-isolation-segment
AWS S3 supports lifecycles for buckets, does this work in Bluemix S3?
http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#putBucketLifecycleConfiguration-property
When I call it (using the aws-sdk nodejs module), I get back a 400 saying 'The operation requested is not supported'. The docs say a subset of s3 is handled but I'm not sure what ISNT't handled.
No, lifecycle configurations aren't supported at this time. The full list of supported operations is on the API overview page. If you want to, feel free to send me an email (nicholas.lange[at]ibm.com) and let me know what you are trying to do. Having developer feedback makes it easier to advocate for prioritizing new feature work.
Also, FYI, there is a new release of object storage that will be available on the IBM Cloud platform (Bluemix) soon, with IAM permissions and OAuth2 support instead of AWS signatures. The docs will migrate there shortly.
I was following the below blog and was trying to execute the POC but no luck. i did follow all the steps as suggested however I could not see any report in google analytics after saving the content. No user is shown in report. Please suggest what could be wrong in my implementation.
Reference Link
It is very hard to give a generic answer without looking into the configuration. I just followed the tutorial myself and it all worked fine (to test, I was making curl calls in the terminal window at my laptop and watching Real-Time / Overview report in Google Analytics.)
First and foremost, please check that _system/governance/apimgt/statistics/ga-config.xml has Enabled set to true, and TrackingID set to the UA- tracking code you got from GA.
One thing to check is whether you are looking at Real-Time report or historical. When you just implemented the change - look at Real-Time / Overview report initially as it starts showing data much faster.
Also, since API Cloud has multiple gateway nodes, it takes time for the configuration changes to propagate. So one thing to try is to wait 15 minutes or so from the time you applied configuration changes in the cloud, and then try invoking the API and see if the sessions are reflected in Google Analytics.
Finally, if these do not help, just submit the support ticket in API Cloud - support is included for free with the cloud service.
I've noticed that the JSON API for Google Cloud Storage is, as it says, "Experimental", and that the URL's I'm supposed to use all have 'v1beta2' in it. It looks like it hasn't been touched since May 7th, and I'm wondering if it's worth creating a new project with this service as primary storage service if I'd want my app to go live in a month or two. Is there a release date somewhere, or is it more like "it'll take as long as it takes"-kinda thing?
Please don't downvote, I wanted to ask this in Google Cloud's own forum as this isn't a programmatic question, but as it turns out - their forum is linking me here to SO asking me to tag with 'google storage' for anything related to it.
The Google Cloud Storage JSON API is marked "experimental" to mark it as an exception to our deprecation policy. As we bring it to full release, there is a chance we may make some changes to the API, and this is why you see the special URLs. We don't have a date yet for full release. You should be able to use it just fine, if you are prepared to migrate your app to the official API when it is released.