Where do I find logging on why there was a failure on an Azure-AD OpenId Connect login?
I've created an application under:
Portal.Azure.com -> Azure AD -> App Registrations
And created a key for the said application under the same location, "Keys".
I'm attempting to use passport-azure-ad to authenticate to the end-point and have it mostly working, but I believe I need more additional server-side logging details to figure out what I'm doing wrong.
Currently, I successfully am redirected by my applcation to the following location where I am given an option to login:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
When I successfully login, I get:
Sorry, but we’re having trouble signing you in.
We received a bad request.
I'm assuming there must be some logging somewhere to tell me more details on what is bad.
Okay, apparently I did not notice the details at the bottom of the error page referenced above, in itty bitty print.
In my specific situation this included:
Additional technical information:
Correlation ID: 891cdfd8-9aa1-4f8b-a538-9accdd9705f7
Timestamp: 2016-10-14 16:38:37Z
AADSTS70001: Application '11111111-1111-1111-1111-111111111111' is not supported for this API version.
Why I'm getting this, I still don't understand; but that isn't really my original question anyway. I also imagine that these details, or additional details are logged somewhere else and it would be helpful to know where they are.
As a result I'm leaving this open to see if anyone has a better answer.
Related
On my signup page i want to check if a certain user with the an email that i specify exists or not. I did try the approach on the answer given to this question (react native firebase check if user already exisits in real time database) but i get an error when i try to do that
I am aware that when you are doing firebase.auth().createUserWithEmailAndPassword it tells you weather user already exists or not, but for reasons that are complicated to explain, i dont want to do that for the time being. I do, however, have access to the config
If the create user func is done on a different page from where the actual form its-self is, then the options are:
Query the results as seen in the link above, given you fix the error
Use Firebase Admin SDK (the better option in my opinion), which gives you access to a number of useful functions, which won't require a form, one of which is:
admin.auth.getUserByEmail(email)
There are several functions that will get you the information you need.
Here is a guide for adding the Admin SDK to your project (should you wish): https://firebase.google.com/docs/admin/setup
In the firebase console you can already set it up under Authentication -> Sign-in method tab and scroll down to the bottom you will see Advanced and set 'One account per email address'
I've just been started integrating assistant to smarthome project that i'm working on. And I've initially experimenting the assistant by implementing account linking flow and sync intent. I tested the account linking by testing with the google developer tool for oauth flow and confirmed it worked. Whereas, in the smarthome app, upon account linking, as soon as it completes the account linking flow I keep receiving an error message stating "Couldn't update your settings, Check your connection". Didn't find much clue with the logs for troubleshoot. And also, the solutions they were on the other posts does not seem to be working out for me as well. Would appreciate if anyone could help resolve this.
Also, I'd like to know the place where I can find the fulfillment URL that needs to be entered when creating the smarthome action. I've been using firebase to deploy my cloud functions. Moreover, I suspect weather the fulfillment URL I entered that was provided by codelabs sample were invalid thus assisant unable reach the fulfillment.
Your fulfillment URLs are the functions that you've created. For Firebase, there's a specific pattern that you can follow. If you visit your Firebase console, in the functions section, you'll see the full URL which you can copy and paste into the Fulfillment URL input.
In my example, I have a cloud function named "about_info" with the pattern https://us-central1.PROJECT_ID.cloudfunctions.net/FUNCTION_NAME. So you can use a similar scheme to identify what your function names will be.
"Issue description copied..."
I'm building a partner connector, which relies on a user name and password to connect to database (very similar to the existing Postgres / MySQL connectors provided by Google). In order to verify the credentials, I also need the database host information to be present in addition to username and password and this is the base of my problem.
The Google build connectors conveniently are allowed to collect user credentials and the database related information at the same time. Unfortunately, that doesn't seem to be the case for partner connectors as stated in the requirements
Point 5 "Use appropriate authentication method in getAuthType(). Do not request credentials via getConfig()."
The authentication itself happens before any other configuration details are known (there is just a dialog for username and password) and there doesn't seem to be a way to request additional information on the authentication screen itself. Once the credentials have been entered, the verification also happens immediately, before the configuration is being shown in the next step.
Once credentials are validated successfully, Datastudio then assumes the schema and data can be requested.This excludes the option of a dummy confirmation, because there doesn't seem to be a way to tell credentials are invalid and need to be changed after checking the other configuration details on the next screen.
That makes me unsure, how to determine valid credentials in my use case as I need to know the variable endpoint to authenticate against. I definitely want to avoid storing any user credentials myself in an external database, because this opens up another can of worms.
Has anyone successfully solved a similar issue before and can provide guidance here?
This is a known limitation of the authentication methods for Community Connectors.
A workaround would be to use authtype NONE and then request the credentials and database information in the config. This is, however, not a recommended approach.
Add me to the list of people confused by all this: https://developers.google.com/accounts/docs/OpenID#openid-connect. I currently use the Python Users API in an AppEngine application running at https://www.stackmonkey.com/. I build the login URL for my login button like this:
login_url = users.create_login_url(federated_identity='gmail.com', dest_url=dest_url)
self.redirect(login_url)
The Users API manages my user DB for me. I'm able to pull the current user's session with this code:
current_user = users.get_current_user()
Given the complete lack of information on the topic anywhere I've looked on Google's pages, I'm wondering if anyone has any information on whether the Users API can be made to work with the suggested migrations, or if Google is going to update the Users API to support the new authentication methods they suggest?
At least I have some time on this, but I'm really not looking forward to reimplementing an entire auth system in my app.
Small update, I've tried creating a sample application running at kordtest2.appspot.com which is returning a 400:
Error: Bad Request
Your client has issued a malformed or illegal request.
The code used for that sample app is cut and pasted from the Python getting started guide on their site (I can't post another link with this account).
I had the same problem, and it appears to be when I was logged into multiple GMAIL/GOOGLE accounts at the same time. When I logged out of all of them except one, that one worked fine with my code, based on the sample Python code.
I'm playing with the oauth2client.appengine Oauth2Decorator and it interjects it's own screen asking for an email address:
The URL is http://127.0.0.1:8080/_ah/login?continue=http%3A//127.0.0.1%3A8080/mypage
I'm guessing that its intention is to mock being different users during development? But that leaves some questions:
Does it only appear on the dev server?
Do I have to do anything to make it go away when deploying to production, or is that magic?
How do I turn it off for development?
What does it actually do?
if the user is being redirected to an oauth consent page nonetheless what's the point of this?
As you can see I just don't get it. I do see that it gives my get_current_user() a result - a user instance with the email address that I submit.
I recognise that this is effectively the same question as
"How to Bypass Local Login Screen with Oauth2 and GAE", which seems to conclude that the whole oauth2client library is fairly useless and it is best that we all go off and write own authentication flows? Seriously?
If that's the state of things alternative suggestions are welcome (in the comments). My workflow is to send the user off to be granted permissions via Google's Oauth so my webapp can proceed to do stuff on their behalf.
If you want to use the get_current_user() that is provided by Google you can't really avoid it and it is actually something very useful. If you want to do your own authentication stuff then just don't use it and you won't be redirected to /_ah/login.
In short this is just to simulate locally the actual Google Login. It would be a huge mess to login to your actual account while on development mode and it will be really hard to simulate multiple users. That code is not executed online and instead you are being redirected to Google for approval.