I have tried to set up every email client available for linux, ubuntu 14.04 and each and every one fails. I'm looking to find what the common element is that causes authentication to fail in each and every instance. Is it because google has changed their authentication algorithm and nobody has kept up with the changes?
It seems that Google, sometime late in 2014 started blocking apps that are using IMAP/SMTP PLAIN authentication by default. It also seems no Linux email client has addressed this change (at least that as far as I have found).
It had only affected me recently. The change only propagated to me now, in February of 2016. I found this out by attempting to install one email client after the other; kmail, evolution, claws, sylpheed, thunderbird. Finally, after reading Gmail blocking mutt I found out that my mail account had been tampered with by Google to reject anything other than OAuth. One way to fix this is to
Allow less secure apps: ON
in the "My Account" settings.
I received a very nice email from Microsoft Google expressing their dismay that I would choose anything other than their email client to access my gmail account:
Hi ... ,
You recently changed your security settings so that your Google Account ...#gmail.com is no longer protected by modern security standards.
Please be aware that it is now easier for an attacker to break into your account. You can make your account safer again by undoing this change here, then switching to apps made by Google such as Gmail to access your account.
Don't recognize this activity?
Review your recently used devices now.
Best,
The Google Accounts team [emphasis mine]
Apparently the only "modern security standards" are Google's security standards. And for why the above is FUD see:
What are the dangers of allowing “less secure apps” to access my Google account?
Also, lmao, apparently "business users" of gmail do not need this security "improvement." I assume this is so because Google does not want to really make a needed security change (otherwise why leave business users out of this), but rather to strong-arm Mom and Pop into using their email software.
Bad Google.
Related
I have an ASP, vb.net, forms-based system. I want to allow people to use PDF documents created within that system to send them to DocuSign and out to others for signature. I have used the DocuSign SDK to build a system that works; however, I am concerned that I may not have the best setup for that.
The problem relates to the "open" nature of this system. Our users are allowed to see and modify all parts of the underlying system, including forms, coding, etc. As a result, a clientID and secret would be seeable to users. And that is concerning.
The system will need to be set to be easily used by our users. So, having users set up a developer account, setting up API settings, etc., will not be something we can reasonably expect.
It would be better if the system did all the interaction and they just had to log on to DocuSign to send the document out for signing. DocuSign has suggested becoming a partner in their referral system. I worry that will still require all the pieces (clientID and secret) that people will be able to see. But, I am not sure that is true.
Will being a partner mean we can avoid having those items saved in an open system where users can see them? Or does being a partner mean some of that is removed or not necessary?
Is there a better way of setting this up so that we can avoid all that mess?
There's no reason that all your customers wouldn't be able to use the same clientID (also know as Integration Key or IK) and secret key (clientSecret).
You will be the only one that can see/set them as the ISV. They will all use their own DocuSign accounts, using your IK. That is abosltuly fine and does not have any limitations.
We recommend ISVs use a single IK per app if it's the same code for the app even if they have multiple customers using the app.
I have a running website, where users already have accounts. And I am trying to create a Google Assistant agent, accessible on Android, to help users access their information.
My issue is that I can't detect returning users on Android Smartphones, each time they have to sign in.
I tried Anonymous User Identity, but it is soon to be deprecated.
Is there an other way to keep track of users?Using some kind of userId that I can store, so I can make "my own Acount Linking" linking the person/Smartphone with already existing user accounts.
There are a few angles to your question.
Is there any way to keep track of users?
Yes... but...
You can store a userId that you generate in the user storage area. You do need to treat this like you would a cookie, so some jurisdictions might impose restrictions on this, but this is one approach to moving from the anonymous ID that is being turned off soon.
But...
How do I let them log into my service through the Action?
That is the problem. The General Policies states the following limitation for collecting user data:
Authentication Data
(including passwords, PINs, and answers to security questions)
Don't collect authentication data via the conversational interface (text or speech).
After a user's account has been linked, PINs or passwords may be used as part of a second verification process.
So you need to use Account Linking to connect to the existing account on your service.
How can I do Account Linking if I don't require Google Sign-In?
You can still use Google Sign-In for Assistant if it will (or may) provide the information as part of the profile that match what you have. So it doesn't need to use the same account - just have the same email (for example).
But that still may not be enough.
For other cases, you can look into setting things up to work with an OAuth server that you control.
So why use Google Sign-In if I setup an OAuth server that uses Google Sign-In?
Google Sign-In is good for a more streamlined flow, if you can use it. It can be done completely with voice, such as with a smart speaker, instead of requiring the user to go to a phone to complete the login. So if you have the user's email address in your account system, and you also get this from Google Sign In, then you can connect the two accounts.
In some cases, such as if the user is expected to have logged into the account on your website first, they won't even need to do that. If both the voice client and web client use the same Google project, then authentication will take place automatically.
I'm using google apps for mail service. I have generated and submitted DKIM records for .co and .in domains successfully. But I'm not able to generate DKIM record for .net domain (say yourdomain.net). It shows an error we are unable to process your request at this time. Please try again later. (Error #1000). I have tried this for 2 .net domains. Both provide the same error. I have tried using in different browser and different machine, and the results are the same.
I am not sure if the issue is with the .net domain or if this is just a coincidence.
Had the same issue today (setup of DKIM on a new GSuite domain) and chatted with Google Support about it.
They pointed me to the following quote on the DKIM setup process.
Important: After you create your G Suite account and turn on Gmail, you must wait 24–72 hours before you can generate a DKIM domain key.
So you'll need to wait 24 - 72 hours after setup of the GSuite account before you can set up DKIM.
I also asked the support person whether I could get access to submit this as a product request (that the DKIM setup is prevented before this time) and he gave me access to the G Suite Feature Ideas (customers only) Cloud Connect Community. I've posted this as a feature suggestion there - upvote if you think this is needed! (needs login):
https://www.cloudconnectcommunity.com/ccc/ls/community/g-suite-chrome-feature-ideas/post/5075513382141952
Preview Screenshot:
I had a "Google Apps for Work" account and wanted to setup DKIM for Google Apps email and another provider and I couldn't do it. I contacted Google Apps support and they said it was a bug with no immediate plans to fix it.
I got the same useless error code you did. I'm disappointed in Google about this. They just leave the broken submit form up, leaving it to the user to contact support to find out it's broken with no plans to fix it.
I'm going to cancel my paying google apps account.
I experienced the same error message when I tried to set up DKIM immediately after signing up for GSuite. It worked when I re-tried about two days later.
We recently switched our team to Google Apps and with that, everyone got a Google Apps account . However, for those of us with a GMail account as well, this makes it so that bringing up Gmail in your browser opens up either your personal account or your Google apps account.
Even though GMail has multiple Sign-ins enabled for both of my accounts, I still have to spend time switching through both accounts.
I was wondering if there was a way to specify the account I wanted to use in the URL directly, which would allow me to create a bookmark for GMail for both of these accounts:
something like:
http://mail.google.com?a=firstaccount#gmail.com
http://mail.google.com?a=workaccount#googleappsdomain.com
I just don't believe anyone at Google has never thought of this! :-)
The same question applies to all of Google's services too I guess (docs, sites, etc...)
https://mail.google.com/a/googleappsdomain.com/
This works like a charm, with one exception: regular gmail.com accounts. https://mail.google.com/mail/ will direct you to the inbox for whichever account you logged in as first. My work around has been to make sure I log into my personal e-mail first (but this at least avoids having to log into the rest in a specific order).
For an access to multiple gmail adresse you can use this :
https://accounts.google.com/ServiceLoginAuth?continue=http://mail.google.com/gmail&service=mail&Email=yourname#gmail.com
I wish there was a central, fully customizable, open source, universal login system that allowed you to login and manage all of your online accounts (maybe there is?)...
I just found RPXNow today after starting to build a Sinatra app to login to Google, Facebook, Twitter, Amazon, OpenID, and EventBrite, and it looks like it might save some time.
But I keep wondering, not being an authentication guru, why couldn't I just have a sleek login page saying "Enter username and password, and check your login service", and then in the background either scrape the login page from say EventBrite and programmatically submit the form with Mechanize, or use an API if there was one? It would be so much cleaner and such a better user experience if they didn't have to go through popups and redirects and they could use any previously existing accounts.
My question is:
What are the reasons why I shouldn't do something like that?
I don't know much about the serious details of cookies/sessions/security, so if you could be descriptive or point me to some helpful links that would be awesome. Thanks!
Edit:
I'm familiar with OpenID and the APIs. I was really wondering about the security/legal/confidentiality side of things. I understand the confidentiality part totally, don't know if there's anything legally written down about this, but assuming it's under ssl, and I don't store any of the data (will store the cookies and tokens), what are the security implications?
If I come to your website and give you my gmail password, what guarantee do I have that you won't read all my emails and even send a few of your own? And what if you become a little smarter and say 'people reuse passwords, I might just as well try if this password works for his bank account'.
As a user, I don't trust your site with my password. Period.
The whole point of Open Id and OAuth (that's what RPX uses) is to get around the above issue. I can give your website restricted, revocable and configurable access to my facebook account, all without giving your website my facebook password.
The UI is confusing, I agree. But with time people will understand what its all about, and it will be a lot better.
As already said above:
The site (or the site owner) accessing your {google|yahoo|etc} account cannot be trusted not to change your password and kick you out of your account.
But I feel there are other good reasons:
Many people use the same password on more than one site ore account (some could have the same password on gmail and paypal) and the site owner could abuse that
The site owner doesn't want to be held liable for other site owners abusing your account
The site owner could not be able to store your username and password in secure fashion. The site needs to be able to access them automatically. So on the server hosting there is stored everything needed to access those credentials.
And the hosting usually happens in a shared or virtual server with the hosting company administrators (and sometimes - if the hosting company isn't too conscious - fellow users) able to access them.
Security and Confidentiality. Period.
Even some websites like Facebook discourage using this approach in their TOS i believe. If so, it will be illegal to do so.