I am working on an IoT project in which I am required to use Google's geolocation API. Well I know it can be called via HTTP request, is there any way I can call it via MQTT as I think it will be more power efficient and have publish/subscribe approach as I want?
Related
Looking at the Twilio documentation it seems that "you create [Access Tokens] on your server to verify a user’s identity and grant access to client API features."
Here, Twilio provides a few different ways to programmatically create Access Tokens on the Server side - it looks pretty straight forward.
I am developing an Android app-to-app calling feature and for this I've have been using the Android quickstart project to go about it. However, for this code, the implementation and execution are done by copying and pasting Access Tokens generated through either the Twilio Console or Twilio-CLI commands.
Say we have our Server set up, a TwiML app and its associated URL, what would be the simplest and most straight-forward way to generate but then retrieve the access token from the Server to the Client app?
According to me, you would like to access Twilio API using an access token. In that case, you should have a backend server that stores the access token because you shouldn't store such tokens in the client-side. Your app would send request to backend which would then use the access code to access that api and forward you the result back.
We are planning to make a recommendations engine for the features in the app and we were thinking about using GCP Recommendations AI. Then, we ran into some unclear areas due to lack of examples.
When we send POST requests from iOS (swift) to GCP, is there a way to get access-token for the header field "Authorization: Bearer $(gcloud auth application-default print-access-token)" using Firebase iOS SDK? Could you please point us to some resources that we can follow. If it's not possible to do easily, what is the easiest secure method that you recommend? Any resources? example use case, we found.
Could you guys please help us with this?
Calling the Google Cloud Recommendations AI API requires that you specify the OAuth2 access token for a Google account.
Firebase Authentication uses a JWT ID token to identify the users. These are not Google accounts, as for example you could create a user with email/password that Google's account system knows nothing about.
It is idiomatic to only call the Google Cloud APIs from a trusted environment, such as your development machine, a server you control, or Cloud Functions. This is done to protect yourself from abuse, as (unlike Firebase services) most Google Cloud APIs don't provide a mechanism to control access directly from the client.
So you'll typically want to wrap the GCP API in custom server-side code, that checks whether the user is authorized, and then call that from within your client-side application code.
I want to use Spotify API and therefore I've implemented Spotify API in my backend.
Maybe this question is dependent to the architectural design but I am wondering best practice.
My backend gets token from Spotify API and I store it. That's Ok.
Should I generate my own JWT token after that process for communicate to frontend? Or, Should I use Spotify Access Token for communicate to frontend?
Best practice in my opinion is to secure every communication path separately.
As I understand from your question your backend talks to Spotify and your frontend talks to your backend and your frontend does not know anything about the Spotify API?
In this case handle both communication paths independend of each other.
Currently I am implementing an Ionic application that the front-end is on the mobile devices and the back-end is on the server. (So there is a connection latency between the device and the server) And my application is using the Google services (like Gmail, calendar, etc) by connecting to the Google API.
Currently the architecture is:
Device <==> Server <==> Google API
This is using the OAuth 2.0 server-side authentication. It works but the connection latency is way too long and feels like going back to the time when we have the dial-up internet connection.
I tried to use the OAuth 2.0 client-side authentication, which is:
Device <==> Google API
This is faster but it has 2 problems:
Even though Ionic packaged the front-end code into an application, I still have concerns that the rule "Everything in the front-end is visible to everyone" stays. (Did not find an evidence to prove or disapprove this hypothesis)
Google API OAuth 2.0 only issues flows to the client-side authentication, and flows expire very often, I don't want the user to grant the permission again and again.
So, I was wondering if it is possible to do the following:
Use the server-side authentication to store keys/credentials (I'm using Django as the back-end, which is Python) and the front-end gets keys/credentials from the server and proceed Google service using JavaScript codes.
I know this is late to the party, but I'm going through this now. I think there are 2 ways to set this up, but neither are perfect.
Use server-side flow to authorize all the scopes you'll need on either the server or the client. When the token is obtained, pass it to your client. The down side is that the client now has a token that has access to more APIs than needed.
Create seperate authorization flows for both the client and server. This would mean the user has 2 authorization prompts, which is no good. The good thing about this approach is you could ensure the client has limited scopes, but the server could still handle the larger tasks (moving Drive files, sending emails, etc.)
In my case, the client would just need read access to the Contacts API, whereas the server needs full Drive access.
If anyone finds a combination approach, where only 1 authorization is needed, but the client and server have seperate scopes, that'd be the ideal situation.
Is Google Cloud Endpoints only intended for App Engine use, or can it be used from anywhere, including our rails app running on Amazon EC2?
You can send requests to an endpoint from any client or server you like. At the end of the day, it's just HTTP. The endpoint code has to run on Google's servers, but anyone can call it. One of the major use cases is to provide backends for mobile apps.