I've been unable to access the Dialogflow console. I've tried logging out and logging back in, clearing site data, using different browsers and incognito mode. I even gave myself Dialogflow admin permissions through Google Cloud Console's IAM.
I've submitted a support request, but waiting on a response. Other folks have asked similar questions on stackoverflow without any response so far. I hope someone can share how to solve this.
You can try to reset your account as indicated in this similar issue from the Public Issue Tracker, specifically follow the steps from comment#2.
If the issue persist, you will need to wait the response from support.
While Isaac's answer here is valid and something that was suggested by the support team as well, the reason turned out to be a change in my email address. The fix was done by Dialogflow's team behind the scenes.
If anyone else faces an issue logging into Dialogflow and have made any change to their email address (including domain) recently, that would be something you would want to convey to Dialogflow's support upfront.
Related
I'm developing a webapp which allows users to log in with their Google accounts, using OAuth2.0.
I've created an OAuth2.0 client ID, configured the OAuth consent screen with the Publishing status set to 'Testing', and added a test user.
The frontend of my app is built with React, and I'm using a package (react-google-login) to handle the flow. I can successfully sign in with the Google account I added as a test user, and retrieve the basic profile information needed.
The problem is I can also sign in with other Google accounts, which have not been added to the list of test users. I imagine that Google should simply not issue access tokens for accounts which are not in the list of test users.
I feel like I've misunderstood something about the OAuth process, or I have configured something incorrectly. I would appreciate if anyone had any pointers?
Thanks.
It is indeed bugged.
I was in the same spot as you, assuming I had misunderstood something. After reviewing my code over and over with no luck, I made a Stack Overflow post, in which I was advised to post to Google's bug tracking system. After doing some troubleshooting with Google they confirmed the bug, and they are now working to fix it (for a little while already).
I included this thread as an example when talking to Google. I meant to post an update here after getting in touch with them, but I forgot, sorry!
The buganizer thread with more details:
https://issuetracker.google.com/issues/211370835
Is it possible you're only asking for the email scope?
It appears the test user filter and possibly the whole concept of the 'app' being in test mode exists only inside the consent screen feature.
For some reason, Google doesn't show the consent screen if you only ask for email.
So... maybe that means you don't need a consent screen, and therefore don't need to care what that feature thinks about your app (that your app is in test mode and needs to be verified before going into production).
Or maybe it's a bug? Or maybe just because you can do this doesn't mean it's allowed by Google's terms. Maybe they just haven't implemented preventing that use case.
Anyway, it may help you to know that if you add a more significant scope like the Calendar API then the following things will change:
Non-test users will get a message like "The developer hasn’t given you access to this app." and won't be able to complete oauth
Test users will get a message like "Google hasn't verified this app"
Test users will see a consent screen
Basically, everything starts working as expected.
By the way, just putting "email" or "profile" for scope seems to be an old way of doing things, and all the newer scopes want you to use a full URL for the scope (despite google themselves not using the full URL when you're configuring your scopes).
For example, if you want the email and calendar scopes, you can put this value for your scope field:
email https://www.googleapis.com/auth/calendar
Or you can use this equivalent value:
https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/calendar
Not suggesting you add a scope like email for the sake of it, just that it sheds light on what's happening, and if there's a scope like that that you need anyway, adding it will solve your problem.
We have just set up a Google Cloud Identity domain, and have a number of users who already have consumer Google accounts using their corporate email addresses.
I've invited several of them to transfer their account to our domain - most have succeeded, but two receive a message when clicking through the process to accept the transfer request.
A pop up appears at the bottom of the screen saying
There was an error. Please try again'.
No further information is given
Does anyone know the cause and/or resolution to this error
Update: My colleagues tried accepting the request a week or so later, and strangely it worked OK. IF anyone else experiences this, it looks like it was a transient issue with transferring accounts into Organisational control.
This sounds like conflicting accounts. This could happen when users sign up for free Google services before their organization signs up for a managed Google Account. If this is the case, there is Transfer tool for unmanaged users.
If info above doesn't help you might want to check if logs contains more details about the error. In Admin console logs, or maybe in Google Cloud Project audit logs.
I need to force my users to fill out the security questions for self service password reset. Ideally when they log into a SP it reads our active directory for the custom attribute associated with the security questions. IF that is blank then force the user into the wso2is dashboard/security questions area.
IS THIS POSSIBLE????!!!!????
Thank you for any assistance.
I have looked through all of the wso2is documentation and forums looking for a solution, still have yet to come across anything.
So I found the answer, it is now included in version 5.7.
https://docs.wso2.com/display/IS570/Managing+Challenge+Questions
Very bottom of article.
Upgrading is fine but if 5.7 can do it, 5.3 should also be able to. Oh well time to upgrade.
I've set up a Django/python web application running on Google Cloud Platform's Kubernetes Engine pods, and secured by GCP's Identity-Aware Proxy.
It all works great, but there are two things I'm not sure how to accomplish.
1) How can I restrict the users to a specific domain, just like the hd=my_domain.com URL parameter does on OAuth2 logging in? That makes the sign-in page only show emails with that domain in the list to click on.
2) How can I enforce that the user logs in with a password, instead of just simply clicking on the account? This is just like when you go to admin.google.com, or security.google.com and even though you're logged in, it forces a password. I know how to go to /gcp/clear_login_cookie to enforce a new login session when I want to log them out, but not sure how to enforce a password is entered. This I believe is called the "user presence test."
Any help is greatly appreciated, I've poured through documentation and have searched various ways on Stack Overflow to no avail.
Both of these items are on our roadmap, though I can't offer a specific timeline.
I don't see an entry in Issue Tracker for either of these. I'll try to remember to add that next week (at which point I'll add the links here), or you can do it yourself: https://issuetracker.google.com/issues/new?component=190831&template=1162609
Thanks for the suggestion, and sorry I don't have a better answer for you!
--Matthew, Cloud IAP engineering
As part of Google's security review of apps that have access newly labeled restricted scopes it was suggested that we update our scopes to a few scopes which are still restricted but are more limited. So, we compiled and submitted an update to our scopes now our app is no longer verified and has to go back through a verification process. In the interim, now our new users when connecting to their Google accounts with our service are presented with very intimidating warnings about the application now being verified.
Does anyone have advice on how to proceed with this? Feels wrong for adjusting to reduced scopes to result in this behavior.
The OAuth Application verification team isn't a support team that can be reached, until they reach out to you. Make sure you've followed the appropriate steps:
You've submitted the verification form.
You or the project owner have received messages from the verification team. Then you can address any questions from there.
Most of the answers regarding the verification process you're looking for can be answered by reading through the FAQ .