I know how to get the device address from the Alexa app.
Now I need the addresses located in settings --> my locations. When I add a business address, I can use this address by saying "work".
I would like to use this address in my skill for work as well. How can I get it?
(Maybe the naming of settings is not 100% correct. I translated it myself.)
I don't think Amazon currently offers this to skill developers. Home & Work addresses are part of the user's Alexa account and would likely be accessed through the Customer Profile, but only name, email, and phone number seem to be available for skills to use according to their Customer Profile API docs.
Skills can only access an individual Alexa device's saved address through the Device Address API.
You can submit a feature request on their Developer Voice and Vote site.
Related
I have two queries related to Alexa Skill -
I am using the Account Linking feature, But when I logged in with one account I am unable to login with another account, any idea? for more information on this please refer here
https://forums.developer.amazon.com/questions/233563/how-to-delinking-an-linked-account-from-my-alexa-s.html
For User Full Name I have created a custom Slot, but unable to fetch Exact Full Name spoken to Echo show device by the user, for example, Use speaks Danny Stone but Alexa device capture it as "Danny", Dannys tone", "Danni" etc.
Any help would be appreciated
For the name, do a two or three slot response pattern on that intent. First name can use Amazon's built in first name slot type. For the other(s), you'll need custom slots with lots of examples.
For unlinking an account, check out this option: https://developer.amazon.com/en-US/docs/alexa/account-linking/skill-activation-api.html#disable-and-unlink
I read your query on the other forum. I would suggest you clear the cache of your Alexa app if you are logging on to your phone. If it does not help then open an incognito browser and disable enable the skill and link the desired account.
Use custom AMAZON.FirstName intent or AMAZON.Person intent for the names. I am not sure that it will be able to recognize some tricky names.
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!
So I'm writing a mobile app and have reached a point where I need to allow users to register a username. I'm doing this by asking for an email address, username and password.
Typically, it's been normal to set this sort of thing up on the web by having the user confirm his email address by clicking on a link sent to his inbox.
Needless to say, on a mobile app this is a bit clunky as the user will be redirected out of your app and into his browser.
So I had a look at how other mobile apps are doing it (WP7) and was surprised to see that DropBox and Evernote both allow you to sign up without confirming your email address. The end result of this is that I was able to sign up with completely bogus email addresses and/or valid email addresses that don't belong to me.
I assume this is done on purpose.
Your thoughts?
I came across the same issue when writing a social networking style app. I chose to have the user create a username and then provide and email and password. I do not verify the email address and I've never attempted to send any email to them (yet).
What I would suggest would be alternate ways to validate a users email address. My app allows users to do Facebook Connect. All they have to do is log into Facebook, and the app talks to Facebook to confirm that they are using a valid email address. No need to verify it with a URL in an email.
I believe Twitter has a similar service and there may even be a few others that provide an API.
I've also discovered that a lot of people just want to tinker around in the app and not create an account at all. It's definitely a balancing act
I'd say it depends on your app and how important it is to ensure users have valid email addresses. In an app I'm creating now, we want to discourage users from signing up with multiple bogus accounts (because our system could be gamed that way) so we're not allowing users to log in until their email address if verified. On other sites however, it might not be such a big deal so why bother users with that extra step?
As for a mobile device, I don't see why you can't still send a verification email that sends them to your website to verify their email address. There are plenty of mobile apps that also have a website users can log into to manage their account.
Another option is have multiple "states" for users. Before they validate their email, they are in a "pending" state. Once they click it, they're in an "active" state. If you store the createDate for the user, you can periodically remove pending users older than 1 week (or however long).
The bonus is that you can easily add more states, such as suspended or deleted.
Personally, I wasn't too happy for users to create accounts with any old email address.
I think a few decent options are:
send a confirmation email with a link that uses a Custom Url Schema to redirect back to the app (although this is only good if they use the link on the same device)
send a short PIN in the email for them to enter back in the app.
send a confirmation email with a web link, have your server confirm the valid email/token, and have your app check the account status either periodically or with some sort of realtime tech like SignalR or Firebase.
I prefer the last one, although hardest to implement. A user might well have their phone in their hand and their laptop next to them, register in the app and try to click the link in the email that just showed up on their laptop. I like the idea of the app then just "knowing" that they've validated.
Do you have a web server? Write a web service that does the validation for you on the server side, and sends back the result.
Either you can use some platform, such as Facebook connect as #Brian replied above, or you may give users a reasonable timeframe to verify, for example, a few days or even a week. After that, the account gets removed.
You can even have your app issue notifications to remind the user to verify his account (such as every day, or on the last date of the verification.
Don't ask for email confirmation on mobile and allow the user to use the service. When the user is using a PC, then ask the user to confirm his email.
I won't defend my recommendation because most of the solutions here are valid. There isn't one correct way. You asked for ideas and here's one.
A good strategy is to allow people to use as much of your app as possible given the amount of data they've provided.
For example, in the case of a newsreader you might let someone browse your app without registering, then require an account for offline syncing, and a verified email for alerts. Always give people a good reason to take the next step, and build engagement first, then people will forgive you pestering them later.
I have an application that uses email addresses for user authentication.
I know that some universities use Shibboleth for user authentication, and I was wondering what the process is for being able to read emails from the university database that is used for Shibboleth. Note that I do not care about authentication through Shibboleth, I only need to be able to read the email addresses.
Is it general for all universities that use Shibboleth, or is each a unique case?
Any links to documentation on how to do this process would be greatly appreciated. Thank you.
Shibboleth can be configured (IdP-side) to release user attributes along with authentication data, for example the user's email address. Client-side, assuming you're going though shibd, you'll need a setting in your attribute-map.xml that says "map attribute with OID x.y.z.a to environment variable USERMAIL" and then you get the result in that environment variable. The example config should already contain it.
This would be the same for everybody insofar as the OID for "email" is always the same, but you'd have to negotiate with the IdPs (universities) or their federations so that they will actually release that attribute to you.
Shibboleth is used by many institutions, but by no means all. Many use Athens, proxies or IP recognition, among other things.
As far as I am aware, a user's email address is not tied directly to the Shib system. When a user tries to access a Shibboleth-protected resource they are taken to their institution's login page to authenticate themselves. They might enter their email address to authenticate or they might enter a username, they might be auto logged-in based on their IP address, or something else.
The institution does send back an affiliation through Shib data transfer upon successful login, something like student#brown.ac.uk but this is not necessarily the email address the user used to login. I guess they could send that but it has not been used in system's I've worked on.
Shibboleth is commonly used to check that the user is from an institution that has purchased access to a protected resource rather than identifying a particular user from that institution so the user's email isn't needed.
Not sure if this helps at all: http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonAffiliation
Should I save this information in the database?
For example when users sign up or log in?
Unless you're tracking the users coming to your site, limitting access based on IP address, or providing geographical services (based on IP lookup)...then you don't need to save this information at all.
Rate Limiting (to protect your resources eg. API)
Security (for auditing reasons - match IP with user credentials)
Geolocation based services (if not now, maybe in the future?)
Data for future load-balancing functionality
Some sites, like banks, will use this info as a security measure. If you try to sign in again from another IP address, you will be asked to confirm your identity.
If you were implementing an auto-sign on feature than you are likely to store this (alongside checking for data in a cookie) to attempt to verify that the computer is the correct one for the user, before auto-logging them on.
Most web servers already log this kind of information in their log file.
You may want to log the IP in order to match up the web logs with your user via the IP (and time).
This will not be 100% correct, as IP addresses can be shared (for example behind a NAT firewall).
Should you do this? It depends. Do you need this functionality? Depending on the answer to this question, you should make your decision.
IP bans for misbehavior. About the only solid reason for collecting the raw IP addresses (and not "cooked" data like geolocation or ISP). If you get several similar ban reasons for new accounts, check the IPs they logged in from, and if they are the same or very similar you may want to block on per-IP basis.
You should save IPs of users only when you have a poll or rating system where anyone can vote once. Also you could store IP data to check for multiple log in sessions so people can sign out other active sessions from your site, like in GMail.
We do a site where the "authorities" of our country often call in and what to have IP addresses from a specific user because of copyright infringements or other lawsuit reasons. This might be country specific but for us, this is a reason to keep some IP addresses of our users.