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.
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.
We currently have two domains, domain1.com and domain2.com
There are Google Apps/Email accounts for each domain.
I would like to migrate the accounts from domain2 over to domain1 so that when you're signed in to account#domain1.com you can send and receive messages from both domains.
I have done this before with my personal gmail however never domain-wide with numerous accounts.
Is it even possible to map all of the addresses like this without having to sign in to each individual account?
You need to migrate the all data (more info). The email portion of the migration (unless you use a third party tool) will be the only part that will be done at an admin level. The rest will need to be done on a user by user basis.
Once you've moved added the data from domain2.com > domain1.com, you need to delete the Google Apps account for domain2.com and add it as a secondary domain or domain alias for domain1.com. If you don't want uses to be logging in with user#domain2.com and only want them to send/receive as #domain2.com, an alias will likely be the best. Info on adding one of these can be found here.
The final step will be setting up a send as on each account so they can also send as their #domain2.com addresses (they'll automatically receive if you add as an alias). These instructions can be found here.
Good luck!
We want to offer users of our (web-based) personal document management solution the possibility to import documents sent as attachments to their GMail addresses.
Our current solution of just allowing our users's to store their login credentials in our web app and then using this to access the user's GMail inbox via IMAP is not only suboptimal from a security standpoint (we'd rather not store the login credentials, if possible), it also sometimes (maybe when we're polling too often or for too many users's) leads to the login attempts of our app being blocked by GMail. We get the error message "[ALERT] Please log in via your web browser: http://support.google.com/mail/accounts/bin/answer.py?answer=78754" from the IMAP server and our user's report that they see that GMail has blocked some "possible hacking attempts" or similar.
So my main questions are these:
Would switching to OAuth for authentication (and still using IMAP to check our user's inbox, just authenticated with the OAuth tokens) help in this situation? I found documentation on how to do this, I just want to know if it would help in this situation.
Are there any guidelines/quotas/restrictions on how often we should / are allowed to poll a user's inbox (or how many connections we open to GMail in parallel etc.)? I couldn't find anything about this in the developer docs at Googles site.
Is there any other way besides IMAP to be able to import attachments from GMail messages into our app?
Answers to your questions
1.Benefit of using OAuth is that you are not storing user's credential directly.So you will redirect user to google login page,where google will authenticate user and provide you an access token and refresh token,you can then access user's emails using access token and google API.Refresh token is to regenerate that access token.
2.Since gmail supports IMAP4 protocol with Idle you can use it to accept real-time notifications from gmail server when new email comes(you dont need to poll gmail every time)
The problem is -
" I have to design one website, which will contain number of blocks. Each block will refer to different email client. That means, a user of this site can see his/her all mail clients in one one blocks."
The user will provide his/her existing mail clients information (Username and Password) at the time of registering into this site.
So, when user comes to the site he will login by providing username and password of this site (and not with user name or password of any of his mail clients) and he will see his home page containing all his existing mail clients opened directly in one one block (without logging in to any of the mail client).
Basically, this website will help the user to use all mail clients in one page.
Will anybody suggest how to do this task ?
It will be better if working codes will be provided.
This sounds quite difficult - you will need to make a good web mail client, and it is very hard to compete with the existing services in this area. For instance, it would be hard to make a webmail client as good as the one gmail has.
If you can make a good webmail client, the rest is quite easy - the user would give login details for POP/IMAP services for each of their email services, and then you could make your server log in to each of them and pull back any mail to display.
It may be easier for you to purchase existing webmail client software, and then wire it up to a database containing user login details to make the website you require.
I've used this component in the past and may help with sending and reading emails/attachement from a variety of sources.
Rebex.net
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.