I'm building a nutrition skill and I want to include some calculators. I could have Alexa ask for the parameters each time something is calculated, but I'd prefer to have users set up a basic profile for themselves to store age, height, and weight values.
I found a small section of Amazon's documentation that talks about how the userId element could be used to store attributes across sessions. Will that work for what I'm talking about though? Or will I have to add OAuth?
There are two way to do this:
1) You can use sessions.
In this method, your data will be vanish when session is end (user stop talking with your skill)
more details https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/alexa-skills-kit-interface-reference#session-object
2) You should implement an oauth 2.0 server to store user data. It is not that easy but you can find some oauth server example in here https://oauth.net/code/
For connecting your skill to your oauth server, you can follow here
https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/linking-an-alexa-user-with-a-user-in-your-system
bonus: If you do not want to implement an oauth server, you can use Login with Amazon (or login with google) services. But you will still need a database server to store data
The userId that you get on your requests uniquely identifies an Amazon account, not a person. Despite the option to switch between different accounts on a single device (see: https://www.amazon.com/gp/help/customer/display.html?nodeId=201628040), the feature to identify people has been discussed (http://time.com/4683981/amazon-echo-voice-id-feature-2017/) but it's not available yet.
As already mentioned in the comments, you will need to persist the session information between sessions and you could use the userId to identify each account.
But in any case, you don't need account linking or using Oauth to simply identify a person.
Additionally, I'd recommend you to stay within the Amazon ecosystem and run your stuff in Lambda (with free tier and with development credits for developers publishing Alexa skills).
If you need help getting started, I have a single-file template for Alexa skills using Python and several examples:
https://github.com/josepvalls/ask.py
Related
I have a flask website.
i would like the user to be able to schedule repeated requests for data from one of their Google accounts (let's say Gmail).
From within the website, the user would first authorize the application to access their private Gmail data. From then on, the application, would retrieve the user's Gmail data on a re-occurring basis, without needing to get authorization each time.
Is this possible? I know it would require a service account but can anyone point me in the direction of documentation that describes how this particular scenario might work.
Would such a scenario be allowed to persist long term? Or will their come a time when Google will require the user to reauthorize the application?
Correction, you should not use App Passwords. OAuth is the correct way to do it I believe:
https://www.oauth.com/oauth2-servers/signing-in-with-google/
Here's Google's docs on it, which is more specific to your need:
https://developers.google.com/identity/protocols/oauth2
I would like to access other users public data to show in my website when they configure the page by their username/id.
It means I will create an app on FB/Instagram side and with the help of this app's access token I would like to fetch public data of other user.
Is this scenario valid now? Earlier it was possible but I am not sure now with changes in policies. Even the documents are not clear enough which can say it's possible or not?
Has anyone tried this out recently?
Users: Only data of users who specifically authorized your App is available, depending on the authorized permissions. It does not matter if data of user profiles is public or not, you have to get permission from each user separately.
Pages: If you want to get data of pages you don´t own, you have to go through a review process with your App to get access to "Page Public Content": https://developers.facebook.com/docs/apps/review/feature/#reference-PAGES_ACCESS
That´s for Facebook, about Instagram you can just hit the docs (as well): https://developers.facebook.com/docs/instagram-api/business-discovery
My number one recommendation, in this case, is Facebook API or Instagram API from Data365. I may be considered biased since it is the tool I work for, but it is really a reliable tool you can get public profile data by users ID or username.
Of course, you can use the official Facebook/Instagram APIs for searching all public objects (post, user, page, event, group, place, check-in). But note, the official API has a number of restrictions. Andyrandy has already described them in his answer. Compared with official APIs, we do not have such restrictions.
Besides, our APIs provide such unique features as gender and age recognition (via face photos) along with identification of post reactions that give a competitive advantage in obtained analytics. Data365 APIs also enable developers to create monitoring tasks for a one-time or auto data update. And above all, we do not break the law but only provide web scraping within the legal framework.
I've been stumbling around for a few hours trying to understand Cognito and identity management in a mobile app. I'm relatively new to mobile app development. I've made a mobile app before, but never one with a back-end. so now I'm playing around with AWS intending to try just that.
I want to make sure that each user using my app can be uniquely identified so that I can store content that they submit to the server associated with them. But I also want other users to be able to see their submitted content. I haven't decided on a data storage mechanism yet (Amazon seems to offer a few), but whatever it is will have to be an indefinitely free service since I'm not planning on spending (or earning) any money on this app.
Part of what is confusing me is the need to create App IDs with whatever service I wanted to use with federated identities. I am starting to suspect there are multiple kinds of identities that I'm getting confused. Does the App have its own identity independent of a user's identity? I didn't expect to have to create Google and Amazon App IDs just to allow users to log into my app using their Google or Amazon accounts. I suspect I'm understanding the API wrong, and I'm having a really hard time finding applicable sample code usable from Xamarin.
I have this much code (unique identifier x'd out):
CognitoAWSCredentials credentials = new CognitoAWSCredentials(
"us-east-2:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", // Identity pool ID
RegionEndpoint.USEast2 // Region
);
And that seemed to run (in a debugger) without throwing an exception at least, but I'm not clear what it has given me. I'm doubting that this credentials object uniquely identifies the user after they might reboot their device, and start the app again the next day. For that I suspect I need something more, and I'm not clear what. What's the next simplest step to get a unique identifier for a user which I can store along with their content to associate it with them?
Are you set on having users use third part identity or do you want to provide user's their own identity? For federated identities (3rd party) you need to provide an Identity Pool ID which is created in Cognito to identify the federated identity provider. For your own identities in Cognito you create User Pools which also have an ID.
If you want to provide user sign-in and sign-up you want to use Cognito identities and not federated identities. The link below has some good references regarding this -
https://aws.amazon.com/cognito/dev-resources/
I have an application that is run on multiple user systems, and using OAuth, allows the users to log in via Facebook, Twitter, etc. The entire point of the user logging in is to get settings and actions that the same user made while logged in on other computers, as identified by logging in with the same OAuth provider + provider user id. The application itself is written in C++ using Qt.
My question is this: how can I save the settings that a user made, and allow them to retrieve it in a secure way? I have a centralized server that I can store information using MySql tables, but I'm not sure the best way to have the user application prompt the server, and receive the data stored for that user.
Any ideas or places you could point me towards?
There are several ways I could think of with this, all have trade offs:
Generally I would store the data in mysql using some kind of string or object encryption/serialization method. I do not use Qt much but http://qt-project.org/wiki/Simple_encryption has some examples of very simple encryption that could be used.
Then the question becomes: What do you use as the key? I would go either with the key provided by OAuth for that user (which could be an issue if users de-authorize the app but still want access to this data) or some other user provided key (which is counter to using OAuth in the first place).
Another option is to go with Qt Users session http://qt-project.org/doc/qt-4.8/qtwebkit-guide-cache.html
This would maybe remove the need to encrypt since it should only be accessible within the users scope.
NOTE: Based on comments below it seems the issue is more about securing communication with the MySQL versus the data inside of MySQL. Waiting on user comments to revise my answer.
I am new to this but I will try my best to explain what I am trying to do.
I have a catalog of products and various private information that my users want to be able to access via their website.
For example:
User-a has an e-commerce site and they want to sell my merchandise. They will be able to access a certain products details via a web service. They will also be able to see the negotiated rate that I've given them along with some other private details.
How should the API handle authenticating the request that comes from User-a's website?
I've been reading all day about different authentication methods but they all seem to revolve around the idea of a third party accessing specific user information. An example is if you let http://randomtwitterapp.com access your twitter profile. In that case, the third party site must manage multiple different users and auth tokens. In our case, my users website is interacting on behalf of the user. I hope this makes sense.
Let's call user A "Alice" because calling her User-A is cumbersome.
Treat Alice's web site as if it were Alice herself. The special pricing and such IS specific to the web site in question, so have it log into your site. Issue credentials that the person developing that site would use to authenticate with, and then use those credentials to determine the pricing and products you show.
As for actual authentication mechanisms, it really depends on your needs. If all you need to do is serve different data to different people, you could do something as simple as an API token passed in the query string: http://api.example.com/products?key=9af4d8381781baccb0f915e554f8798d
Or if Alice already has a username and password for your site, you could have her use those in her API requests with Basic Auth.
If Alice is going to need to enter her account information on various sites that she doesn't control, then oAuth comes in very handy. With that, you can essentially give her an API key for every site she needs to access your API from. And you give her the ability to delete those API keys and deny those sites access.