I'm creating an application that creates google apps accounts using a WWW application. User for which we are creating that account provides his personal e-mail address that will be set as an recovery e-mail address (it really makes sense in this case!).
I couldn't find a way to set user's recovery e-mail address. Is there a way to do this programatically.
Like the phone number used for recovery and Login Challenges, I don't believe it's possible to set a recovery email address for a user upon provisioning (via the Apps APIs). This needs to be something the user or users do manually once they gain access to their account as a best practice.
Related
I have a domain which uses Google Apps for Business to handle email. I already have it mostly set up--MX records point to the correct location and my domain is verified.
I'm now writing a python app (with Django) that will need to serve mail from my domain. What's the correct way to do this with Google? Should I create a Google Apps "user" for the organization as a whole, and then authenticate via SMTP as that user and send mail from there?
The Gmail API says that it
is the best choice for authorized access to a user's Gmail data.
and that
Automated or programmatic message sending
is a typical use case. However, I'm not trying to access a user's data or send mail on behalf of a user, but on behalf of my domain. What's the correct way to proceed?
Any help much appreciated!
You could use SMTP or the Gmail API based on your description. In both cases, you'll need some sort of service account to send mail from. With SMTP, as you mentioned, you'll be authorizing via the instructions you linked.
If you choose to use the Gmail API route, you'll be authorizing the API usage with the account. The Gmail API has many other use cases (e.g. to access user's data) but you're only using it to send emails on behalf of a service account you control.
Suppose I have an email address abcd1234#gmail.com, I would like to check whether this email address has been used in Apple,Facebook,Twitter and so on. (used means it has been registered as an account).
How to do it with programming? It there any open API ? Any language will be fine.
No. A feature like this would be a security risk, because finding valid account email addresses is the first step in getting control over the account (second step is retrieving the password from somewhere).
There is no such api, this seems to be really unsecure thing.
The way I can see for you to do this – try to register a new account with this e-mail address, and view the result.
I have a web application that allows registration and authentication through Facebook, Google and Windows Live. Each OAuth request has the required scope to retrieve associated e-mail addresses from the authentication provider.
The current situation is that an account is created based on the provider and the provided identifier. This means that if a user has logged in with multiple providers the user will have multiple accounts on the web application.
I want to have the ideal situation of having a single acccount even when using multiple providers. I was thinking about using the e-mail addresses to see if an account exists for the user. If it exists, use the account based on the e-mail address.
How safe/reliable is this? Do all OAuth providers mentioned validate e-mail addresses? Better ways?
EDIT: Ran a tests and came up with this. Still looking for further advice :)
FaceBook: Cannot authenticate with unvalidated e-mail. Additional e-mail will not appear until validated.
Google: Provides `verified_email`. Additional e-mail will not appear until validated.
Windows Live: Cannot authenticate with unvalidated e-mail. Additional e-mail will not appear until validated.
Interesting question. You could try to use e-mail to check if user exists, but the problem is, user could be using different e-mail addresses for different providers.
My suggestion would be asking user (once he/she logs into your application using one of the methods) to attach other providers to to this account, so he/she can use them as well to log into your application.
It doesn't completely solve your problem (I'm not sure if solution exists), but user will have more control that way and you'll reduce the amount of accounts per user.
my question is about the workflow of a web registration.
1) register with email + basic data
2) activate the account with a special secret link <- is this necessary?
3) allow the user to log in to the system
EDIT: I want to make the process as simple as possible without a password to choose/remember.
In more detail:
After a user is registering on a web site I sent out a confirmation with a generated password to login on the site and proceed.
Many sites sent an activation link first and then allow logging in to the system.
Is there any reason to do this additional step when I generate the password and sent it out to the user?
Thanks for your answers.
Is there any reason to do this additional step when I generate the password and sent it out to the user?
To ensure that the provided email address exists, and belongs to the person who registered the account.
I've noticed an increasing number of websites which skip this step. It seems to be a trend.
The purpose of the activation link is to guarentee that the email address provided by the user is one to which they have access. If you are generating a password and sending it via email to the user's email address, then the link is not required (because them logging in means that they read your email).
However, email is generally not a secure way to distribute information over the internet. You are sending them the password in plaintext, and you do not know how many people have access to that email account (e.g. a shared family account). I think you would be better off allowing the user to choose their own password at registration and then send them a link (offer to generate a password for them on the registration page, if you really believe that generating it is better).
The validation of an email account is usually to help prevent someone creating numerous accounts. This helps prevents spammers and various other bad people from attacking your site from different accounts.
In general you're trying to ensure that the person is who they say they are and that you have an outside means of communicating with them.
1 - to ensure that the email is belong to the registerd user.
2 - to make it harder to the people want to create many accounts (like forums where a single person have so many accounts to use them in voting or somthing).
I remembered a funny site that gives you a 10 minutes email , just to skip the process of creating a new email or even spamming your email by the sites you've registered in.
This way you make sure that the email address is valid and it will be more difficult for a spider to generate many users than without this step. Also, you might do a lot of things in your database when a user is registered and you can do these after the user is validated, to save time by not creating extra traffic on your database server for fake users.
I'm building a system that allows people to submit text and photos via email in addition to standard access on the website. I'm trying to weight the security advantages of two strategies in particular for verifying submissions from a user. Here they are as follows:
To based auth: Create a secret email address per user and present this to the user for submission. This strategy has the advantage that people can send from multiple devices that might be setup with different mail accounts
From based auth: Only accept emails from addresses that are registered in the user database. The idea being that it is impractical/difficult to impersonate registered users based on the sending address.
Can you think of other possible solutions? Which strategy of the ones proposed makes the most sense to you?
I would suggest that you not use From based authentication, at least not without some additional credentials (a passphrase, etc)
It's way too easy to forge, and certainly not difficult if you know someone's email address.
If you echo the email back to the user for confirmation, you can make things a little more difficult, but realize that your service can end up being used as a sort of spamming relay. (I could send 100 upload requests to you, with a forged FROM address, and you'd go ahead and spam the real person with 100 confirmation requests)
The better option is to check the registered email address but add the need for a code within the email subject known to the user. This way if they forge the email from address, they would still need a key to authenticate the incoming email.
I would go with "from" + confirmation, to avoid forging.
I.e. receive the email, but send a response with auth token in the subject line (or in the body) back to the "from" address. The user either will need reply, or click a link to confirm the submission.
And you post the content only after confirmation.