All my hardware is already developed. I use MQTT for communication between my devices, I have lights, fans, heaters and many more ioT appliances. I can controll all of these from my Android application which i have built. I would like to use Google Assistant to control my devices as well. The status of my lights (on/off) are stored in a sql database and when ever a change occurs to the database(detected by the hardware) my hardware can control that specific light. In My Android app i do the same thing which is updating the databases value(on/off) of the light and the change is detected by my hardware platform. Can i use Google Assistant to update a sql database value?
I can create a webserver( ASP.NET C#) and pass the command to the sql database of my relevant customer if google assistant can invoke the username or email, lightID, command to my webserver. Can google assistant do this? If not how would achieve this.
It sounds like you want to take a look at the Actions on Google Smart Home API which will let the Assistants Smart Home controls work with your control server directly.
Without knowing exactly how your database or existing web server are configured or hosted, I can speak only broadly at best. Your web server will need to implement two primary things:
You'll need an OAuth2 server that can issue tokens that represent your users. This is how Google will associate the user's account on the Assistant with your account, and how Google will identify (to you) which user is issuing the command.
You will need to implement a webhook at a URL on your web server. This webhook will be sent a POST message containing a header with a valid auth token (that you issued) and a JSON body. The JSON will contain information about the command that has been issued by the user. Your HTTP reply body will also be JSON. For details of the JSON formats and all the fields that it can send and that you must reply with, consult Google's documentation.
There are a number of different commands (which Google calls "intents") that Google can send you on behalf of the user. You should be able to handle all of them by either querying or modifying your database:
SYNC - A request for what devices this user has, some of their configuration information, and what commands they respect.
QUERY - What is the current state of the devices for this user.
EXECUTE - Change the state on some of the user's devices.
RESYNC - (Future update) A re-request of the user's device info.
Related
Here is my scenario. Imagine there is a Yoga studio that uses a professional booking and reservation system that exposes an API. Through this API an application can make a reservation for a client. The API takes the client's userid and password to make the reservation. The booking API doesn't use OAuth or any social media sign-ins.
My desire is to create an Assistant Action that would retrieve the list of classes and allow the client to make a booking.
My puzzle is what design/architecture to look towards to supply the userid/password pair required by the booking API.
How have others solved this puzzle?
Should I store the userid/password as "user state" associated with the action?
First, you should have a conversation with the API provider about why they don't provide an OAuth-based solution. This is a security vulnerability waiting to happen, if it hasn't already.
Second, you need to think very carefully about your own risk profile in this case:
Google does not allow you to collect credential information (ie - passwords) through your Action.
Because of this, you must use Account Linking to authenticate them.
This means that you will need something (ie - a database or data store) to manage their account on your side.
This database would be a good place to keep the username/password you need to use for them for the API...
...but it now means that you need to take extreme care about protecting this database.
You don't really say how this API allows for accounts to be created and managed. If these accounts are just used for you (ie - the user doesn't necessarily see them), then you can mitigate some of that risk by treating the username/password as an opaque token that you manage and generate and that the user never sees.
If this is something that the user is aware of, then you'll need to approach the account linking in one of two ways:
Have them log into your service via an app or webapp using this credential info that you will need to save (ack!) and then link to the Assistant using OAuth.
Have them log into your service via an app or webapp using Google Sign-In, which will carry over to your Action. Then have them provide the credential info for the API, which you will need to save (ack!).
I'm using adjust and firebase in my ionic app but the app secrets for these integrations and others all show up in my app's js code if I extract the APK/IPA.
How do I keep credentials secure and package them with the app's APK/IPA for such hybrid apps?
This is an interesting question and it's good that you are asking it :)
For the Firebase settings, they are secret, but not secret-secret. They are just a starting point. Nothing can be done with those unless the user also logs in with their password which is hashed using the secret key and then sent over.
This proves that the person knows enough to identify themselves as a user.
Then on the server side, you have your rules that say "for the person that has identified themselves as user X they have permission to do Y"
If somebody has got your password then you are exposed just the same as you are always exposed.
You can also restrict your Firebase account by apps package id, hostname, IP address, in the Google Cloud admin panels.
As for your other things, like Adjust, they have their own solutions along the same lines. Either the API key is just enough for you to read the information, or if its a powerful level of access then normally there is some kind of authentication/account linking process so you can prove yourself to the other API.
If not, then you cannot just put it out there, you need to create your own proxy. Firebase supports cloud functions (aka serverless) so you can run snippets of code which are only accessible by users that have logged in, and then return that information back to the client as a proxy.
This got stuck in my head from many days, can anyone help or say at-least this is not at all possible?
I'm working on developing a chat bot using dialogflow which integrates multiple applications along with google home assistant, dialogflow, actions on google and an application which i want to manage using chat or voice commands. Until now its good and got amazed of features providing by google.
But i'm expecting one more feature. Don't know whether any alternatives available for this or not, but i tried exploring and reached to desert. Below are my requirements, if others think this is really unique and useful to them as well then i can say they are improvements or add-ons i'm expecting from DialogFlow.
Let's take an example of a chat bot which is serving users through google assistant and as a web bot as well. Now while conversing, intents may trigger web-hook in fulfillments which may require an authentication like OTP(Nope if anyone thought it for payments) which means registered users or limited users only can perform actions. This is same as we use roles and groups in all the applications.
The way google is sending google prompt to the user for logging into gmail, is there any way that we can collect PIN or OTP or PASSWORD through some notification sent to the users phone as some card's or input box like and html while conversing with chatbot through web or home assistant etc..., so that it helps in adding more security.
I recently worked in a chatbot project where I had to authenticate my users. I'm writing an article about it, but I'll tell you what I did:
First of all, I'm using OAuth 2.0 protocol to authenticate my users, but if you doesn't use OAuth, there's no problem, you could do something equivalent.
I'm using Authorization Code Grand flow.
Let's see the steps:
Step 1 - Authorization Url:
My bot generates an authorization url which contains all needed data to identify the conversation in callback moment. Like this one:
https://authorization-server.com/oauth/authorize
?client_id={your-client}
&response_type=code
&state={conversation_id: 123456789}
&redirect_uri={your-callback-url}
Notice that the state parameter contains the conversation_id which identifies your conversation, this state parameter will be back when users return to your handler.
Step 2 - User Authentication
When users click in this link, they'll be redirected to your login page at your authorization server.
Step 3 - Callback
After users get authenticated, they'll be redirect back to your handler (an endpoint which will receive the authorization code from authentication server and the state parameter).
When it received this authorization code, it'll be exchanged by an access token in authorization server.
Step 4 - Store token
In the final step, you already has an access token and the conversation_id parameter, you can store it in a database, in a cache or be stateless. Your rules!
In my case, I'm using Watson Assistant with Cloudant database, and I store those access tokens in my database. So, when users request something to my bot, it could get this token from database and pass to my back-end servers.
This kind of approach, I call "magic link". And you could improve it by shortening the url as bit.ly does.
I hope it could help you, feel free to ask me if you need.
Best
You probably don't want to implement the OTP scheme yourself. While you could do this, there are other systems already in place that will do this for you.
The best is the one that you reference - Google Sign In.
Fortunately, you can leverage Google Sign In for both your website (where you would get the user to sign in and then pass this information along as you do the Dialogflow calls) and for the Assistant (where Google will pass along an ID token, indicating it has authenticated the user).
I want to build a Conversation Action for Google Home device and control its access. Only certain devices can invoke some actions. How can this be done, once the agent is publicly deployed?
Think of Google Home the same way you would think about a web browser and an Action the same as a web page or site. If you wanted to limit what web browsers can access a public site on the Internet, you're somewhat limited.
You could restrict access to certain IP addresses, and this will work in some cases - but it means that access via non-static IP addresses aren't possible, and if (ie - when) a machine gets a new static IP address, you have a lot of work to do. Similarly, the Google Home device can send a random user_id string for each unique user, and you can use this to limit who has access. But this string can change by the user resetting their Google Home device, and when it does, you will have to deal with that.
A better solution on the web is to allow people to log into your site. This way you can have a public facing web page, but only people with accounts can access. You can determine how to hand out accounts, so this is very flexible. The equivalent with Google Home is Account Linking where you will maintain an account as part of an OAuth2 system that you control. Google Home will ask for permission to access your system, and you will issue OAuth2 tokens to Actions - these tokens will be passed back to you for each request, and you can verify that the user has access.
I strongly suggest going with the Authorization Code Flow since this seems to be where Google is focusing on providing additional features - such as signing up to your service through Google Home.
I have tried Google with queries similar to the title of this question, but haven't found anything useful.
Background: I am building a web app and would like to add a user authentication level to it. I cannot imagine anything worse than building a user authentication system from the ground up, so I want a quick solution.
I'm looking for open source software I can host on my server that provides an auth layer I can connect to, with multiple user accounts
Criteria:
I want to host the software on my own server
Provide a log in screen that works with multiple sign in strategies - twitter, facebook, vanilla email, etc.
Persists users to a database (preferably postgres) and persists session data
Preferably lets me store a minimal amount of data per user, like key value store
Has a client-side (Javascript) API, like Facebook's JS, so I can use this auth service on multiple sites. Namely, I want to use it on localhost or my own file system (when allowing file cookies). Client side JS API exposes methods like log in / log out
Has a server side API (such as exposes local RESTful endpoints) so that when I do build out my server side app for other data storage outside of the user, my app can query the auth service for log in status.
I want to run this stack completely independently of my own app - in fact I want to run this auth service and purely communicate to it from my local dev environment without building any server side app of my own.
I have used Firebase and they do many of the things that I want, including log in strategies and the client / server side APIs, but I want to be able to host my own version of this.
I can't imagine anyone takes pleasure out of building user authentication of any kind, so I'm surprised I haven't found anything in research.
I also know this is an open-ended question, but as far as I can tell I haven't found anything satisfying my requirements.
I like Devise (https://github.com/plataformatec/devise), which is for Rails. It has an active community with a boatloads of plugins available that can fulfill many of your requirements.
I didn't see a language specified; most languages and frameworks have their own implementations. Can you provide more information?
Example: I use the Flask framework on python. In addition, I use the Authomatic library which provides Oauth access for twitter, google, facebook, etc.
What I was looking for is something called a Single Sign On solution. According to this list there is nothing currently that meets my criteria.
Instead I have chosen to just run a local webserver and implement a regular auth flow.