My company has an application that was verified through the Google OAuth Review/Verification process and is listed as "Published" in the Cloud Console; however, end users are starting to receive the "This app isn't verified" warning when needing to re-authorize.
We tried emailing them Google Cloud Platform/API Trust & Safety Team directly but immediately received the reply "Please note that your email was not received because api-dev-oauth-verification#google.com is not a monitored alias."
Since the application is verified in the console, the "Submit for verification" button is greyed out so we can't contact them that way and we don't want to modify the scopes to require verification again as we want to preserve everything so Google can investigate it in its current state.
That's why I'm reaching out here:
Has anyone experienced this before and have any ideas what could be the cause?
Anyone know a way to reach the Google Cloud Platform/API Trust & Safety Team without the use of "Submit for verification" button?
You are receiving the "api-dev-oauth-verification#google.com is not a monitored alias." message because the address you are trying to send the email to, is a bit wrong.
The correct address to contact the trust and safety team is:
**
api-oauth-dev-verification#google.com
**
Remember that only the project owner should contact the T&S team.
Related
I am trying to obtain my production keys for my QBO app following the steps in this link
here
However, when I try to start the "App Assessment Questionnaire", I get the error message below:
You currently do not have a developer account, please click here to complete setting up your developer account. Once that is complete you will be able to access the help pages.
This is what I see, and I DO have a developer account. It won't let me continue.
Please help!
UPDATE
I see this error in the address bar:
ErrorCode=ERROR_CREATING_USER&ErrorDescription=License+Limit+Exceeded
UPDATE #2
I tried creating a brand new account, a new app, on a different PC and the same thing happened. So this is not a cache issue.
UPDATE #3
Created 2 support tickets for this issue
#00114423
#00114415
I had to use a different account to access the help site
https://help.developer.intuit.com
I've the same issue since Friday (02/18) and spent hours to figure out what's the problem.
tried from different browsers and different IP addresses
made a brand new developer account to test with it
had a 1+ hour chat session with QB support (but not developer support)
sent an email to an address received from the chat assistant
sent a feedback at https://www.surveymonkey.com/r/AppAssess
According to the browser's developer tools:
the Start questionnaire button opens this URL:
https://developers.intuit.com/app/developer/appdetail/prod/questionnaire?appId=xxxxx:UUID_of_app
then it redirects to:
https://login.salesforce.com/services/auth/sso/yyyyyyyyyyy/Intuit_Enterprise?community=https://help.developer.intuit.com
finally, SSO to salesforce fails and it redirects back to:
https://developer.intuit.com/app/developer/qbpayments/docs/qbms-payments/hosted-paypage/faqs/help-redirect?**ErrorCode=ERROR_CREATING_USER&ErrorDescription=License+Limit+Exceeded**+-+Customer+Community+Login&ProviderId=xxxxxx&startURL=%2Fs%2Fquestionnaire%3Fapp%yyyyyyyyyyyyy
So, it seems to be, QB have reached a license limit at salesforce, which prevents new logins to create and the questionnaire from to load.
And the funny part is: the same thing happens, when I tried to create a support ticket and used the "Ask a question" button at https://help.developer.intuit.com/s/
Which means, I can't start the questionnaire and can't start a ticket about the error either.
I guess, if QB developer accounts whom created support tickets previously or started the questionnarie before the license limit has been reached, they have have a SSO login account at salesforce and able to fill in the form or start new support tickets, but others are stuck because of the license limit.
If somebody have a working QB developer account and able to start a support ticket, please do it, and link this page in it.
Or maybe, we should contact salesforce support to let QB know about the license limit.
I'll give it a try.
This seems to have been fixed. I tried running the questionaire and it worked.
I have also been having this problem the last several days and had the same lack of success with QB support. The URL callback error I see is:
ErrorCode=REGISTRATION_HANDLER_ERROR&ErrorDescription=Please+sign+the+terms+of+service+before+you+login+to+community
I don't see anywhere I can sign a TOS in my account page - it's possible that in fact QBO hasn't signed a TOS with Salesforce. What a joke.
I'm trying to send an email using the java api. I've got my app running live, no custom domain, in fact it's just a default project. Billing is not enabled. My app name is 'testapp'.
I'm using this email address for the sender:
admin#testapp.appspotmail.com
That seems to be ok if I'm reading the docs correctly (criteria #2):
For security purposes, the sender address of a message must be one of the following:
The Gmail or Google Apps Account of the user who is currently signed in
Any email address of the form anything#appname.appspotmail.com or anything#appalias.appspotmail.com
Any email address listed in the Cloud Platform Console under Email API Authorized Senders
The email was sent successfully twice, but now it has stopped working (same sender address, same recipient address). Nothing appears in the recipient's spam.
I can see in the quota page that the # of emails-sent keeps incrementing. But nothing is actually going through.
What am I missing?
Thanks
This is a known issue that is currently being tracked on the App Engine public issue tracker. Please feel free to star this issue for updates.
Here's the situation: I have successfully set up email to come from a custom domain on App Engine before, but that was always done through the Google Apps for Business set up process. This time I have added the custom domain through the new developers console instead (https://console.developers.google.com/project/[APP_ID]/appengine/settings/domains) and now I'm getting the "unauthorized sender" error every time.
I've tried a lot of variations on the set up process, checked for typos or other potential bugs repeatedly, and scoured both the docs and Stack Overflow without finding an answer. Most of the docs and answers that come up seem woefully out of date. The docs hardly ever reference the new developer console or the fact that Google Apps for Business doesn't have a free tier any more. And most of the answers seem to ignore the fact that the docs (https://cloud.google.com/appengine/docs/python/mail/sendingmail) explicitly state that "Domain accounts do not need to be explicitly verified, since you will have verified the domain during the registration process."
So has anyone actually gotten domain accounts to work with the new process? Do I have to modify DNS records? DKIM? Something else I'm missing? Any insight would be much appreciated.
As stated in the docs:
For security purposes, the sender address of a message must be the
email address of an administrator for the application or any valid
email receiving address for the app (see Receiving Mail). The sender
can also be the Google Account email address of the current user who
is signed in, if the user's account is a Gmail account or is on a
domain managed by Google Apps.
So only logged in Google accounts or admin (owners in the new console) addresses can be used to send emails through GAE. If you want to use a set of custom domain addresses you can either:
1) Add and validate all those addresses as owners in the project's "permissions" settings.
2) Use as external party to send your emails through a Web API, EG Sendgrid which gives you 25.000 emails/month for free for GAE developers (https://cloud.google.com/appengine/docs/python/mail/sendgrid)
I am faced with a rather strange request and there isn't much material online tackling that.
I am building a web app on GAE ... front end, back end, datastore, blob store, user accounts, the whole nine yards ...
Part of the requirements is to have a user communication system, (users sending messages to each other, just like Facebook) as user emails are not to be shared among other users, and the web app shall only send emails to the user sign up email strictly for security and administration purposes, and wont flood their inbox with notifications like some websites do.
I have narrowed narrowed it down to 4 options
Option 1:
Reinvent the wheel - Build this whole system form scratch on the Datastore and Blob store. However, not only is it expensive, but also I am not gonna go through all of that (just saying honestly)
Option 2:
Build a bouncing system ... User A sends message to app ... app bounces email to User B. Not very Elegant, impossible to create threads and conversations, eats up app Mail Quota used for Marketing and what not.
Option 3:
Host My own Email server onsite. Patch an API servlet and run the whole show through API. Very valid, except that the client doesn't want anything on site, and I wont be around to maintain it for him.
Option 4:(Best option if someone helps out)
Implement option 3 on a 3rd party email provider. Which brings us to the question, is there any respectable email provider that allows account sign up through API ?? I need to create a shadow email account on a 3rd party server(that the user will never know it exists) every time someone makes an account on my app. Then store all emails and their generated passwords in the Datastore, and when user logs in my web app, web app logs in 3rd party server, retrieves messages and serves it. When he wants to send a message, web app gets the message, sends an email using API as well. If someone knows how to do that on Gmail, I would be eternally grateful (but I highly doubt google allows that)
Note
I can implement the whole setup on xmpp/Jabber servers as well but these free servers keep changing all the time and they change their configurations ... bottom line they are not very reliable.
Thanks a lot guys !! I really appreciate any feed back and if you have any other suggestions please don't hesitate !! This is by no means a solid plan yet.
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.