Anyone is having problems retrieving Likendin connections with new apps?
With old apps my hybridauth app is retrieving connections just fine. While with new apps (I created 3 different apps) I keep getting Access to connections denied
When authenticating I got the correct scopes on likedin login screen(r_basic_profile, r_network, w_messages, r_emailaddresses)
Im using free plugin http://wordpress.org/plugins/wp-social-invitations/ which uses hybridauth
This is a recent problem with the linked. They have stopped providing member connection in their recent API change. Now you have to obtain a partner certificate in order to access member connection information. Even my production application has stopped this functionality to work. We might be removing linked from our application as it is of no use now with so much of restrictions.
Linkedin api changed recently, that's the reason scopes are not longer working
The get connections API in linked in has been deprecated follow this link to get the API' that are allowed as part of developers program right now.
Related
I am attempting to integrate my NEST devices with Home assistant so following these instructions: https://www.home-assistant.io/integrations/nest/
I have created a google cloud project, enabled "Smart Device Management" and "Cloud Pub/Sub" APIs, configured OAuth Consent screen which is now in production and configured OAuth Application Credentials - which generated a client ID and Secret.
I have also paid the $5 for the device access console so can access this screen:
However when I go through the process of creating a project, inputting the OAuth Client ID and submitting, it will try for a few minutes and then get the following error:
Really not sure what I am doing wrong. Any help would be greatly appreciated.
I just encountered the same thing. I don't think it's you. The endpoint to actually create the project is returning a 503-Service Unavailable response. Likely a temporary issue.
I am encountering an issue as well
Marko seems to have discovered that it is on them right now
I had the same issue yesterday. This morning I logged out of the Drive Access Console and then logged back in with the same gmail account and my project was there.
I had this issue as well and I finally figured it out.
After spending more time than I care to admit on it, I realized I could create a project if I skipped the "OAuth Client ID" step. I was then able to go into the project and add the Client ID from there.
What happened is that I had been copy/pasting the Client ID directly from the Google Cloud Console. For some reason, copy/pasting directly from Google Cloud Console adds extra spaces to the start and end of the Client ID string. After I got rid of the extra spaces, I could create projects as expected.
I wish the errors were more descriptive.
Sorry for my english...
I'm using firebase authentication for first the first time.
I discovered that I cannot create/connect to accounts if my network automatically selects dns and does not use google dns(8.8.8)
I do not understand how my application will work (just I think that not everyone uses this DNS).
Is there any way to fix this so it works for everyone?or is it work correctly?
without google dns
with google dns
Please check any that applies to you,
Is your ISP is blocking DNS queries to Google Authentication servers,
Are you using a proxy, if yes try disabling it, and then try again,
Check the error returned in auth callback when you are requesting authentication,
Check stack trace in LogCat of Android Studio.
We've had an .NET Framework 4.6/Asp.NET MVC app secured for some time with Azure B2C, enabling sign in with social providers and with a workplace Azure AD account. We configured this more than a year ago with custom policies, when the Identity Experience Framework was quite new, and it has worked successfully ever since.
In about mid-January, some users started experiencing an issue. Sign in with B2C would complete correctly (and be logged as a success in the audit trail), but the user identity would remain unauthenticated. This has now spread, with many users affected, signing in with social providers and/or the linked external AD, but with some users not affected at all (suggesting perhaps an issue with new cookies, whereas old unexpired ones are good?).
The issue can be replicated in testing, and a clean browser will fail to log in multiple times, then succeed perhaps once, or twice, before returning to failing. The success rate is perhaps 1/20, and seems higher with VS 2019 in debugging mode, suggesting perhaps some kind of timing issue.
The fact that it does work very occasionally seems to suggest there isn't anything wrong with the configuration. All traces to Application Insights, as well as the B2C audit log, show successful logins, but the user identity in the Asp.NET site remains unauthenticated. We've tried stepping back in Git as far as the middle of last year, and those older builds experience the same issue, although the code has been functioning in production all this time.
One further oddity. When I inspected the Azure B2C tenant to confirm no keys had expired and no other changes had been made (none had), I discovered it was no longer associated with our subscription - a warning message directed me to attach it. We had certainly done this previously, as we could not have used the Identity Experience Framework otherwise. We don't understand how it could have been removed from our subscription - no such action appears in the activity log. Reattaching it, however, has not fixed the issue above.
What could be happening here? Why would a previously solid app begin malfunctioning in mid-January? How can we debug this when all the logs show a successful authentication? How did the tenant remove itself from our subscription?
Happy to post code if it will help, but I would emphasise that a) this was working previously; and b) it still does work intermittently.
Update A long and helpful screen-share with Azure support has confirmed that the B2C login process is working correctly, but something (unknown) is going wrong when redirecting back to the application. The JWT looks good. What could this be?
Further Update Two escalations and further long debugging, and this still isn't fixed. It seems the login completes absolutely correctly, but then the Asp.Net application somehow doesn't trust the result. The JWT looks good, but the user in the app remains unauthenticated (or somehow loses authenticated status at once). Has anyone else hit this kind of issue? What could be going wrong?
With help from the Microsoft Asp.Net support team, we managed to diagnose this as an instance of Katana bug #197 as described here: Application stops generating login cookies
The solution was the well-known app.UseKentorOwinCookieSaver();
https://github.com/KentorIT/owin-cookie-saver
Although we had implemented this fix previously on our Azure AD secured Asp.Net sites, we hadn't needed it previously on a B2C site. We're still not clear why this issue reared its head suddenly on a site that had otherwise been operational and stable for more than a year.
I have successfully deployed a Google Cloud Endpoints Developer Portal for my API running on Endpoints. I would like to provide access to testing to people outside my organisation that are not using GCP in their projects.
Login to the portal works correctly if I enable the Service Consumer role for these people (on per-email basis). However, when they open it for the first time, they are being asked to grant some extra permissions to the portal:
This form can create totally unnecessary security concerns. Does anyone know, why is it needed?
I only would like my clients to be able to test my API using a GUI, before they could start connecting their projects (not necessary on GCP) to mine. This seems to be a valid use case for me, however I might be misunderstanding some basic concepts.
Or should I submit a feature request to Google about a new role that only enables the access to the portal, and nothing else, so no such forms are shown?
Since Endpoints APIs must be explicitly shared with customers, the portal needs to verify that the logged-in user has permission to view that Endpoints API. So the short answer is that these scopes are being requested primarily so the portal can check the user's access to this API.
Longer answer is that we (the Endpoints team) are looking into if it's possible to build narrower OAuth scopes that would correspond to the access checks we perform. We agree that it's unnecessarily broad of an access request and are hoping to improve this in the future. Thanks for your comment!
I have built a asp.net app that successfully accesses o365 exchange with an App Only Token and Graph. I am now trying to access a specific user's OneDrive for Business files with the same token and a Get request similar to the following:
https://mycomp-my.sharepoint.com/_api/v2.0/drives/simon#mycomp.com/items
but I get the following error:
3001000;reason='There has been an error authenticating the request.';category='invalid_client'
Any idea what is the cause of the error?
It's possible to do app-delegated access to OneDrive for Business today using the direct API endpoint and the Sites.ReadWrite.All app-delegated permission scope in AAD. I'd consider it more "in preview" than supported, so Yina's answer is technically correct. I'm still getting the documentation for how build an app finalized, but we'll be publishing something soon.
Andrew Connell has a good blog post about how to get this setup, available here: http://www.andrewconnell.com/blog/user-app-app-only-permissions-client-credentials-grant-flow-in-azure-ad-office-365-apis
Use of the OneDrive API is possible using this same method.
App Only access to a user's OneDrive is not supported via Microsoft Graph at this point in time.