I'm trying to connect my website's API and mobile app. I need to authenticate the user with google account but I don't know how to do it.
I created the backend with Django. And I set the endpoint as rest-auth/google/. On the restframework's page, it requires Access Token and Code but honestly I don't get how I can test if it actually works using actual google account.
I want to test from mobile app but I don't understand how and what I need to POST.
Anyone could give me tips?
I would recommend you to use a ready solution like "django-allauth".
If you want to do authentication yourself you might want to read Google's documentation about the topic:
https://developers.google.com/api-client-library/python/
In nutshell you create API credentials:
https://console.cloud.google.com/apis/credentials
Send a user to a link with specific parameters (api-credentials, scope, redirect link etc). Google client can help you to generate it.
A user will login in his account as he would normally do and will give your app permissions to use his information (or won't). After that he will be redirected to the link you specified with GET request with a code as a parameter (or error).
With help of Google client you can exchange the code on a token and then use that token to get information from his profile.
I've been trying to test Google Glass Mirror API but I guess it's dead since they've quit its development.
Requests are made to this url (https://www.googleapis.com/mirror/v1,), but it states "Not found". Playground itself is open, but doesn't send anything to the device.
Does anyone know if there's a way of overcoming this? Or if they changed the server location?
Sincerely,
Apidcloud
If you are trying to access the exact URL you specified (https://www.googleapis.com/mirror/v1), it won't work. That isn't a valid endpoint itself for the API. All of the API calls are to URLs that start with that prefix. For example, once authorized, the URL https://www.googleapis.com/mirror/v1/timeline should get the timeline items for the authenticated user. Other paths either retrieve or take action.
If the playground is not sending anything to the device, that is usually an indication that you didn't auth the playground and the device against the same Google account. Make sure you follow the auth directions listed on the Playground page.
I have a Silverlight 5 app that runs on a SharePoint 2007 site. The Silverlight app gets a bunch of data from SharePoint lists using the Lists.asmx service. The main site is secured using NTLM security and Silverlight is able to successfully call the web services without having to eplicitly set anything to do with authentication. We extended the SharePoint site to a second domain that uses asp.net FormsBasedAuthentication. On this version of the site, the first web service call fails with a 403 Forbidden response and the exception:
System.ServiceModel.CommunicationException: The remote server returned an error: NotFound. ---> System.Net.WebException: The remote server returned an error: NotFound. ---> System.Net.WebException: The remote server returned an error: NotFound.
As I understand it, this is a generic message and not the true exception. Well, obviously we need the real exception to have any idea what the problem is. This MSDN page (Creating and Handling Faults in Silverlight) offers two solutions to getting the real exception.
The first is to modify your WCF service to return an alternate HTTP status code. This doesn't work because for one, it is not a WCF service, it's an .asmx web service so I can't add the suggested WCF behavior to modify the status code. Second, it's SharePoint's service so I can't do much to modify it anyway. Could I modify IIS to achieve an equivalent solution somehow?
The second solution is to register an alternative HTTP stack in the Silverlight application. I tried this out and found out the "real" exception was an authentication exception. So I went down dead ends trying to figure out out to get authenticated for about 24 hours only to finally find out that normally, the ASP.NET authentication cookie is passed with the service request, unless you are using the Client HTTP stack. So registering the client HTTP stack allowed me to see real exceptions, but it created its own exception which seems to only be fixed by not using the Client HTTP stack...
I believe have verified with Fiddler that the authentication cookie is being sent when using the default HTTP stack. I don't know if the Lists.asmx service is unable to use it and is giving an authentication error anyway, or if there is some other exception. How can I determine the cause of the "The remote server returned an error: NotFound." exception?
Well, this isn't a good answer to the quesion "How can I determine the cause..." but it's what worked for me. What I did was open up STSSOAP.dll, the assembly containing the Lists service implemention, in reflector. I copied the relevant code to implment my own GetListItems method in my own service. Luckily, the actual Lists.GetListItems method code was minimal and just called other SharePoint methods and even luckier, those methods & members are all declared public so I was able to do this. I then replaced Lists.asmx with my version on the server and attached the debugger to get some info. What I found was my authentication cookie was being used and HttpContext.Current.Session.User.Identity.IsAuthenticated was true. So it knew I was logged in. But I was still getting an authentication error which I could see farther down in SharePoint's code, was converted to a 403.
So I know asp.net considers me authenticated but SharePoint says I don't have permissions. But the service account the app pool is running under is a SP admin so why don't I have permissions? So next I inspected the SPContext.Current.Web.User; SharePoint's current user. It was null! In other words, as far as SharePoint is concerned, I'm still logged in as an anonymous user because I haven't explicitly logged in with a domain user, and an anonymous user doesn't have permissions on the list I'm accessing or most of the rest of the API. The answer by Sean McDonough to this quesion lays it out.
Basically I need to run the involved code with elevated privileges to get the code to run under the asp.net service account that I originally thought it was running under. If using the API, you can use the RunWithElevatedPrivileges delegate. But if you're calling the web services, you can't do that. The few options I could think of were:
Call the services on the base site that uses Windows Authentication. This would require me to embed the credentials in the client-side Silverlight application which is a security threat so I nixed this one.
Implement my own web service to get the data for me.
The web service could access the list using the SharePoint API and
RunWithElevatedPrivileges.
The web service could call the Windows Authentication site's services passing the current credentials or other embedded credentials.
For implementation ease, all I've done so far is the second option under number 2 and it's working. However, it is clunky and I may change to option 1 which I expect will also work.
I'm very novice when it comes to web applications and ASP.
Recently, I've been experimenting with the Microsoft Sync Toolkit to synchronize databases over a OData web service.
The obvious question here is: Once the service is set up and published - so it is open for anyone knowing the URL - how to prevent unauthorized users from accessing this service.
Please note: Basic authentication of forms authentication - as far my little web development knowledge reaches - doesn't seem to be appropriate for this task, as it's not a web page that the client is trying to reach - where the page can display / or re-direct a logon request - it's a service that we are accessing here.
To make things more difficult, for the client-side syncing I'm using a 3rd party library/sync-provider that only accepts a URL for the service. So, there's no way (I think) I can experiment with incorporating login credentials inside a request header etc.
I assume the best bet would be embedding the login credentials inside the URL and use that for the 3rd party library.
Can somebody please direct me how to to set up such thing on the server? I would prefer to have somehow somewhere in the server-side code a place where I can check for the credentials and based upon it to proceed or abort (return 401) the service request.
I could not find any place where to hook such code into the sync service. Although somebody in MSDN suggested to handle the _OnBeginSyncRequest event, there is no way to access the web-request header from within that method.
Is there by-any-chance a global object accessible from everywhere from which I can access the request header? Could anyone please help with this?
And last, I would prefer a plain User / Password string pair. It should not necessarily (or rather not) have anything to do with windows or directory accounts. I would prefer in my code to simple check against plain strings, such if(userStr == "Authenticated user" && passwordStr == "Correct Password").
if you are using SOAP web service, you can use WS-Security usernametoken which adds your user name and password to the request header, otherwise you can add username and password as parameters in your webservice and then simply validate it on the server side. i.e.
instead of
bool SyncData(datatable)
it becomes
bool SyncData(datatable, username, password)
note for web service you will authenticate per call, if you want to do it per session, you need first login with username password, retrieves a token than on each subsequent call your service with the token.
You would also use SSL to secure the channel so username and password aren't transmitted as plain text.
As a proof of concept for a simple background application, I used the Graph API Explorer to create an access token for my app to post something to the wall of a page I maintain. It worked fine. Naturally, however, the token expires.
So now I'm trying to have the background application automatically request a new page access token each time it runs. And I'm having a lot of trouble finding a concrete definition of how to do that. There's no shortage of information regarding Facebook and Access Tokens, but nothing seems to demonstrate how to have a background application post to a page. (Not post to a user's wall, not display a login dialog to a user since it's a background application, etc.)
I can fetch an access token in code easily enough by reading the response from a web request to this URL:
https://graph.facebook.com/oauth/access_token?grant_type=client_credentials&client_id={MY_APP_ID}&client_secret={MY_APP_SECRET}
Of course, that "access token" doesn't work when trying to post to the page's wall. It says that the user hasn't authorized the application to perform this action. The action I'm performing is pretty simple:
var client = new FacebookClient(GetFacebookAccessToken());
dynamic parameters = new ExpandoObject();
parameters.message = "this is a test";
dynamic result = client.Post("{MY_PAGE_ID}/feed", parameters);
I've read in some places that I'll need to make a second request, using the first access token, to get the page access token. But I can't seem to find examples of how to do that.
Can someone shed some light on this for me?
I have a Facebook page.
I have a Facebook app which serves no other purpose than to provide a means for a local background application to access said page.
I just need that application to be able to authenticate so it can post something to the page.
(And if there's a step I need to perform in the Facebook UI to permanently give the application permission to do this, I think I've performed that step but it would be good to double check somehow.)
Edit: It's been described to me that I need to obtain a long-lived user access token and, using that, obtain a page access token. The theory is that said page access token won't expire. However, what's not clear to me is how one accomplishes this.
I've read the page describing the deprecation of offline_access, as well as the page describing server-side access. However, I'm clearly misunderstanding something. In the former, it references the latter for obtaining the proper token. The latter, however, includes steps for presenting a login to the user, having them accept permissions, and using the response from that login.
Being a background process that runs unattended, presenting any sort of question to a user (which would be me) isn't really an option. I've also been told that I can't do a one-time request from my browser to get an access token because that is, by definition, client-side interaction and not part of the necessary server-side flow. (It seems odd to me that the service would care if a RESTful request comes from a web browser vs. from an application, but I'm not familiar enough with OAuth or the Facebook API to really make that call.)
So, if I can perform some manual steps to get a permanent access token for the app to post to the Facebook page, what are those steps? Conversely, if I can perform some automated steps in the application to acquire access each time it runs, what are those steps?
(Making a few more API calls from the application adds a second or two of running time to an otherwise once-a-day process, so it makes no difference to me which approach to take.)
At first I just went into the Facebook Application settings and re-enabled the deprecated "offline access" permission. Said application settings can be found at a URL like this:
https://developers.facebook.com/apps/{APPLICATION_ID}/advanced
However, since everything keeps referring to that setting as being "deprecated" then I didn't want to use that as a long-term solution. It may get removed entirely, it may be unsafe in certain circumstances, etc. Better to use recommended functionality.
So here's what I was able to piece together from a scavenger hunt through updated documentation, outdated documentation, a sea of outdated internet posts, and PHP code which mostly made assumptions about functionality that aren't true in all cases...
Visit the Graph API Explorer and select your Facebook Application from the drop-down menu. Click "Get Access Token" and select the permissions you want. (For mine I went to the "Extended Permissions" tab and selected "Managed Pages" and "Publish Stream.") You will be prompted (in my browser it was in a new tab) with a familiar screen where the Facebook Application is asking you, the user, to grant it the permissions you just selected. (You've seen this before if you've ever agreed to use a Facebook Application before.)
The value it produces in the Graph API Explorer (a long string of random-ish characters) is your "Short Lived User Access Token."
As described here in "Scenario 4: Client-side OAuth and Extending Access_Token Expiration Time through New Endpoint" access this URL in your web browser:
https://graph.facebook.com/oauth/access_token?
client_id={APPLICATION_ID}
&client_secret={APPLICATION_SECRET}
&grant_type=fb_exchange_token
&fb_exchange_token={SHORT_LIVED_USER_ACCESS_TOKEN}
(You can obtain the {APPLICATION_SECRET} value on the basic settings page for your Facebook Application: https://developers.facebook.com/apps/{APPLICATION_ID}/summary)
This will return another Access Token as such:
access_token={LONG_LIVED_USER_ACCESS_TOKEN}&expires=5184000
This access_token value (another long string of random-ish characters) is your "Long Lived User Access Token." The expires value is in seconds, which translates into 60 days.
Now we hop over to the Page API reference and take a look at the section on Page Access Tokens. This, along with the basic structure of Graph API requests exemplified here (scroll down to the part where it shows a bulleted list of sample links which include access_token specifiers, which you'll need to specify here because you're requesting non-public information) leads you to request this in your browser:
https://graph.facebook.com/{FACEBOOK_USER_ID}/accounts?
access_token={LONG_LIVED_USER_ACCESS_TOKEN}
This will return a JavaScript object containing lots of useful information about the Facebook Pages and Facebook Applications your user account controls. In my case the Page and the Application had the same name, but it's easy to tell them apart from the category values or, if all else fails, the id values. Find the Page that the background application running on your machine will need to access and copy its access_token (the third and final long string of random-ish characters). The whole node looks something like this:
{
"name": "Some Facebook Application Name",
"access_token": "{LONG_LIVED_PAGE_ACCESS_TOKEN}",
"category": "Musician/band",
"id": "{APPLICATION_ID}",
"perms": [
"ADMINISTER",
"EDIT_PROFILE",
"CREATE_CONTENT",
"MODERATE_CONTENT",
"CREATE_ADS",
"BASIC_ADMIN"
]
}
This is your "Long Lived Page Access Token." This is the value you use to initialize the FacebookClient object in the code. Then, posting a simple status update is as easy as:
var client = new FacebookClient("{LONG_LIVED_PAGE_ACCESS_TOKEN}");
dynamic parameters = new ExpandoObject();
parameters.message = "This is a my status update.";
dynamic result = client.Post("{FACEBOOK_PAGE_ID}/feed", parameters);
Supposedly this "Long Lived Page Access Token" does not expire after 60 days like the "Long Lived User Access Token" does. I'll find out in 59 days, I guess.
NB: The curly braces in my examples are part of the placeholder for actual values. Do not use the curly braces in the actual requests. So something like this:
https://developers.facebook.com/apps/{APPLICATION_ID}/advanced
becomes something like this, for example:
https://developers.facebook.com/apps/123456/advanced
where 123456 is the actual Facebook Application ID.
Being a background process that runs unattended, presenting any sort of question to a user (which would be me) isn't really an option.
As I already said, you only have to do it once.
You get your non-expiring page access token, copy&paste that into your app – and from then on your app can do server-side whatever it wants to do happily everafter.
I've also been told that I can't do a one-time request from my browser to get an access token because that is, by definition, client-side interaction and not part of the necessary server-side flow.
The server-side auth flow for getting a user access token also needs to take part partly in the browser.
It does not matter, if you get a short-lived token via the client-side auth flow and extend it afterwards, or if you get a long-lived one using the server-side auth flow.
(It seems odd to me that the service would care if a RESTful request comes from a web browser vs. from an application […])
Facebook does not want users to give their login credentials to any third party. Therefor, the process of getting a user access token always has to take part in the browser, with the user login in to Facebook.
So, if I can perform some manual steps to get a permanent access token for the app to post to the Facebook page, what are those steps?
Get a long-lived user access token with manage_pages permission. (Or get a short-lived one, and extend it). And then, use that long-lived token to request a page access token for the target page, in the way that is described in the docs.