Within a custom Alexa skill hosted as a lambda service, I need to call an external API with an API key, that changes for each device. So I can't put the URL or the API Key hard-coded into the skill's code.
Whats the best practice to store user settings locally like an API Key for an Alexa skill? I tried to create an intent, where the user can dictate e.g. the API key, but it doesnt really work quite well and is not that user friendly. Unfortunately, I dindt find a way to create some sort of user preferences site, that might be accessabble for example through the Alexa app on the connected iPhone.
Each request comes with a User ID that uniquely identifies the owner of the device. I use that as a filename for an S3 bucket, retrieving that json file on my Launch intent and storing the info in the session vars. You can store anything you like in the S3 file and retrieve it per user.
There is no way to save any info without writing the code to do so. When the skill is first loaded, all session vars are empty. You need to write code to use the user id to lookup necessary info.
Related
I’m trying to create an Alexa capability that creates reminders without user voice invocation. To achieve this Alexa suggested to use “Out of session” interaction event i.e Skill Messaging API (https://api.amazonalexa.com/v1/skillmessages/users/{userId}), as you can see in the API we need to pass the user Id, In order to get the user Id Alexa suggest to do first account-linking, once linking is done we’ll get the user profile access including userId. Now, after hitting the Skill Messaging API with received userId, it returns
{type:”not_found”, a message ”invalid user Id”}.
Not sure where am I going wrong. Has anyone phase the same problem.
In the request shown next, set HOST to one of the following, depending on the user's region: api.amazonalexa.com, api.eu.amazonalexa.com, or api.fe.amazonalexa.com
I am developping an Alexa Skill within the one the user has to provide a serie of answers to my backend (node.js) in order to get the right result. I would like to send this result by email.
Is it possible to retrieve the user's email through the API put at disposal by AWS using the Dialog.delegate method?
Thanks !
There is no built in method can get you the current user email id or any personal info.
But with authentication you can. See this blog post. You'll need to create an Amazon App and link it to your amazon skill using Account Linking. For the first time when you ask for the email, user has to accept access with their Alexa app. You can then save this email in your DB for future purposes. This is a long but recommended method.
The simplest method: Whenever the game is finished you can manually ask the user for email address. But Alexa may not recognize email address spoken by users properly and might break your app. I don't know, but maybe Alexa will reject your app for asking personal info this way!
I have an alexa skill and a website. I need to send requests from the alexa skill to change a certain variable on a website.
for examble, I have a name on the website lets say "michael", I want to be able to change that name to "zack" from alexa.
Alexa skill SDK allows you to perform remote calls to third-party APIs.
In your case, you can implement an API endpoint to change that field. Then you can call that endpoint with the data you need.
You can capture the name your user has been said.
By doing that, you would need to think how you will authenticate the user. Basically, you need to know how to match the user who is using Alexa with the user on your website. I don't think you want to change the name for the random user.
I am making a hybrid mobile application, using Ionic and Cordova, for which I would like to give the user the possibility to sign up/log in with Facebook, G+, Linkedin and Instagram, and email account. I would indentify everyone by their email (to check if it's the same person, it is not a pk in the database but just an index).
I have been looking around for information about OAuth2 and looking into the documentation for the services APIs. I have understood what I have to do in the front, but I have some questions on the whole process:
[BACK] How do I check the tokens provided by the services APIs? Let's say when a user logs in with Facebook, I get a token which is stored in the user's phone. Then, on every HTTP request, I have to attach the JWT to verify the user indentity. How do I verify it? Against what do I have to test it?
I want to be able to get information from the user's G+ account but also the user's Linkedin account (example). How do I manage this properly?
Do I just store both (or more) tokens (in local storage) and use them to authenticate? I want to do this as my app will have "friends lists", so the user will be able to log into external services and the app will get the user's friends/contact list from those apps.
As of now, I think about including an auth_method field in my database to store available authentication methods (a JSON string or something like that), and just add four fields (one for each service) default null where I would store the token created for the user.
I can show you my code but it do not think it would help as these are more of theory and not specific to a language.
Thank you for all the help!
I'd like to give to each of my customers access to their own bucket under my GCS enabled app.
I also need to make sure that a user's bucket is safe from other users' actions.
Last but not least, the customer will be a client application, so the whole process needs to be done transparently without asking the user to login.
If I apply an ACL on each bucket, granting access only to the user I want, can I create an API key only for that bucket and hand that API key to the client app to perform GCS API calls?
Unfortunately you only have two good options here:
Have a service which authenticates the individial app according to whatever scheme you like (some installation license, a random GUID assigned at creation time, whatever) and vends GCS signed URLs, which the end user could then use for a single operation, like uploading an object or listing a bucket's content. The downside here is that all requests must involve your service. All resources would belong entirely to your application.
Abandon the "without asking the user to login" requirement and require a single Google login at install time.