Using Facebook graph Api in c# windows application - c#

I want to start with graph Api in windows application. I created a facebook app and see some articles about graph Api but unfortunately I did not understand. I want to get data like: Messages, Events, Friends, Wall posts,... from facebook.
What is the first step for this?
What is access token and if it is a constant string or changes for every request?
Do you have a very basic sample for this?
Any help will be so appreciated.

Access token will expire in 2 to 3 hours and we can extend it for 60 days. For that we need to create an application in facebook. And based on this access token will be vary and not constant.
** What is Access Token **
An access token is a random string that gives an app temporary and secure access to Facebook APIs. And access token can be created on behalf of a person, a Facebook Page or an app. The token is generated in the last step of the login flow. Facebook SDKs handle the generation and storage of tokens automatically. Apps using other methods will need to follow the login flow to create tokens.
The token stores information about permissions that have been granted as well as information about when the token will expire and which app generated it. To maintain information security, almost all API calls at Facebook need to have an access token passed in the parameters of the request.
Go through this link for Graph API

Related

dropbox-sdk-dotnet: how to get a refresh token and update the access token

I'm using the Dropbox SDK for DotNet, and it is time to support short-lived Access tokens.
My use case is uncommon (web site, 'backend side'). Once the link to DropBox is made, everything should keep working unattended.
In fact, it is OK to never publish the app. Each user creates its own app in their own Dropbox account and stays on Development mode forever.
Until now, the user created the dropbox app, takes note of the App key, App secret and generates an access token directly at https://www.dropbox.com/developers/apps/info/....
With this data, the application was working fine, but Access tokens will soon be short-lived only. I already verified the like to dropbox gets broken after the generated (from www.dropbox.com/developers/apps) Access Token expires.
How can I, using the SDK and having a valid Access token, get a refresh token to be saved and utilized to get a renewed access token?
I couldn't find any way in DropboxClient.cs, DropboxOauth2Helper.cs, not the examples at https://github.com/dropbox/dropbox-sdk-dotnet/tree/main/dropbox-sdk-dotnet/Examples
It is not possible to use an access token to retrieve a refresh token. A refresh token can only be retrieved via the OAuth flow. I recommend reading the OAuth Guide for more information.
The "Generate" button on the app info page on the App Console does not currently offer the ability to generate a refresh token, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though.

Xero oAuth 2 authorisation

I have a .net core web API server that I connect to from a mobile application. The server creates an invoice on Xero and sends the user an email etc...
I have been using oAuth 1 with no issues, but now need to switch to oAuth 2. As there is no front end-user on the API server, can this still be accomplished?
All the documentation I read, seems to need a manual login to grant authorization and get an access token?
I was using the XeroApi settings in my appsettings.json file with a pfx certificate and a private app.
I am using the C# SDK
Thanks in advance :-)
You'll need a user from the Xero organisation to go through the OAuth2.0 flow at least once to retrieve an access token. If you request the offline_access scope during this flow, you'll receive a refresh token as well; this will enable you to refresh the access token from your web server on an ongoing basis, without user intervention.
So yep, you'll need a manual login at least once, but as long as you request & retain the refresh token from that initial flow, once should be enough.

Dialogflow, Google Account Linking and ASP.NET Core API (Webhook)

I am a student working on a NLP app for the Google Home for my senior design project. I am wondering specifically:
What is the correct way to implement Google Account Linking and what does Google Account linking provide for registering/authenticating users via Dialogflow (i.e. what the dataflow looks like from initial query to Google logging in, back to Dialogflow, then to my ASP.NET Core API handler).
Does Account Linking return a bearer token in the header back to Dialogflow and thus, back to my handler? Or do I have to parse the originalRequest JSON object to get the user information then validate it against the identity provider?
How can I get the user’s information from the Dialogflow request in my webhook (ASP.NET Core API)? Do I have to parse the originalRequest JSON object to get the user info? From my understanding, and from this awesome tutorial, the HttpContext should be populated after verifying the JWT token. What is still unclear, is how to get the token from Dialogflow and Google Account linking.
I appreciate any help or guidance you can provide for implementing user authentication/authorization from Dialogflow to my .NET webhook.
Lots of questions. Let's take them one by one and try to clear up some things.
What is the correct way to implement Google Account Linking [between the Google Assistant and my system]?
First - you need to understand what Account Linking is.
It lets you provide a way for you to authorize a user access to your services. Google uses this to connect a Google Assistant account to an account on your system.
Since this is against your system, the "correct way" depends on your infrastructure. But in general - it means that you'll be issuing OAuth tokens for Google to use and hand back to your webhook. Details for what is expected are in the Actions on Google documentation.
To be clear - you need to be an OAuth server.
What does Google Account linking provide for registering/authenticating users via Dialogflow?
Nothing.
Well, mostly nothing.
All it will do is hand the user off to your OAuth authorization endpoint if it does not already have authorization for that user. It expects you to hand back tokens that it will use.
Does Account Linking return a bearer token in the header back to Dialogflow and thus, back to my handler? Or do I have to parse the originalRequest JSON object...
The auth token (which you have issued, because you're the OAuth server) will be sent in the JSON object at originalRequest.data.user.accessToken.
...to get the user information then validate it against the identity provider?
You are responsible for validating that the access token is one that you issued and is still valid and then... doing whatever you want with it. One assumes that you'll use it to figure out who the user is, however. How you do that (looking it up in a table, passing it to another service, getting the info out of a JWT, etc) is entirely up to you and how you've implemented the OAuth service and what the format of the token is.
How can I get the user's information from the Dialogflow request?
It depends what "user information" you're expecting. By default, Actions on Google and Dialogflow won't give you any information unless you ask for it - and you don't ask for it via Account Linking. You ask for it via using the Actions on Google permission system. But even the permission system won't give you information you may want (most people want email address - which you can't request).
If you want to do it via account linking - you need to request that information when you setup their account.
Do I have to parse the originalRequest JSON object to get the user info?
If you are using permissions, then yes.
If you're not, then while you can parse the JSON to get whatever is sent (the anonymous user ID), it won't just give you information from their Google Assistant account.
Account linking isn't about getting access to their Actions on Google account - it is about getting access to the account in your system when they access your service via the Google Assistant.
HttpContext should be populated after verifying the JWT token
That article talks about using Firebase Authentication as the OAuth server and how to handle it as a client.
Actions on Google turns this around. You need to be the server. It is the client.
It is certainly possible to build a server that uses Firebase Authentication to authenticate users if that is what you wish to do, and to issue JWT tokens as your bearer tokens, but neither of those are requirements.

wp8 c# azure client side authentication mobile services issue

I am just starting out with a windows azure mobile services .net backend, and am running into so many headaches as a new programmer. I have gone into my azure mobile services account and downloaded the todoitems demo app (c# for .net backend). I then followed the tutorials regarding adding facebook authentication, but I am absolutely not pleased by this method, as it shuts down the app for a few seconds. As such, I set out determined to create a custom authentication login page which ties to my mobile backend.
I found this article and thought, "Great!" only to realize that I had no clue how to catch a user created account from a textbox and to pass it along to the public class RegistrationRequest. The example at the end of the link shows how to connect to a local machine - but I want it to connect to my actual database at the following location: https://mycustomapp.azure-mobile.net, return a token, and continueon.
What is frustrating is that I am able to obtain a facebook authentication token, as well as user information. BUT, I have no idea how to generate a windows azure mobile auth token so that the client may write/retrieve data from my azure table.
Essentially my question is this - using the above link, how in the world may I take a user's username and password from a textbox, run it through the RegistrationRequest, and not have to pop advil on this? Do I need to pass my facebook token? I assume not?
I am also not using a facebook SDK or anything like that - simply put, I am using the above site's code trying to get an auth token from my azure mobile services, despite having one from facebook already, to authenticate a user against my azure mobile services data table.
If you already have a FB token, the easiest way to login to your mobile service is by using the FB token, then you don't need to make a custom UI/etc.
This can be done by calling
var token = new JObject();
token.Add("access_token", "access_token_value");
await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook, token);
see: http://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-dotnet-how-to-use-client-library/#authentication, Client Flow for more
if you want to login to your service with a Facebook account, you do not need to implement a custom authentication and to capture user name and password in your own textbox controls.
You should be able to use MobileServiceClient.LoginAsync() and pass as parameters the provider that you want to use. Check this article fro more information.

Facebook API App Access Token cannot access Ads Data

I am trying create an automated process to pull Facebook Ads data with the c# Facebook api (facebook.ddl) on a daily bases. The process needs to be fully automated so that no human intervention is needed. I was able to pull the data when using an "user" access tokens; however, the “user” access tokens expired after a short period of time (e.g., 2 hours) and required a user to confirm the request for a new token. It other words, any implementation of an user access token would prevent me from fully automating the process. Next, I tried to pull the Facebook Ads data with an "app" access token but the process failed with an error message related to security/permissions. Currently, it is my understanding that "app' access token were not design to access Facebook Ads data. Is this correct? If so, I would like to know if it is possible to pull Facebook Ads data via a fully automated process and (if it is) how to do it?
You should exchange the short exchange the short-lived 2 hour token for a 60 day long-lived token. Process is outlined here.

Categories

Resources