I am developing an IM client for iPhone, which will have support for an FB account as well. I am using facebook-ios-sdk for getting auth token.
But whatever token I fetch, it does not contain any "|" character as a delimiter. Isn't it supposed to be like <app-id>|<session-id>|<digest>? Thats what I have read. Now, there is no such delimiter. How do I go about fetching the session key now? Or is there any new method for XMPP communication?
Further, is this one of the changes in OAuth2? I see that it will be deprecated from Nov 5 (as of latest update), so the delimited string will not work after that? So that instead of using older authentication mechanism, I should be working on the new mechanism?
I would be really grateful if you could provide some documented evidence regarding this. Thanks.
from where u get the said format?
the access token that you received is likely to be an encrypted token. In your fb app settings, see if the option "OAuth migration" is enabled or not. If it is enabled, then try to set it to disabled and see if this helps.
I found what I was looking for here:
Any way to pull out session key from access token returned by Facebook iOS SDK?
So the point is that with Single-sign-on, we cant get a token that can be used for xmpp. So if you want to make a chat app, you must use the dialog method, and for that, make the changes as suggested in that answer.
Related
Anyone used epicshaggy / capacitor-native-biometric plugin and have been able to make it work. I have just been able to trigger the NativeBiometric.verifyIdentity( function and make it recognize my biometrics, but that's about it.
I've crawled the internet and haven't found a complete example of how to use it. To summarize, i just want to understand how can i use biometrics to login a user. How do i make my server uniquely identify a user and provides login token.
According to the CapacitorJs docs, and epicshaggy/capacitor-native-biometric, the correct way to work with user credentials is with the provided methods:
NativeBiometric.setCredentials()
NativeBiometric.getCredentials()
NativeBiometric.deleteCredentials()
These methods
Securely stores user's credentials in Keychain (iOS) or encypts them using Keystore (Android)
These methods are also only available on native devices, hence "method not implemented" when attempting to run in a browser, and must be behind Capacitor.isNativePlatform().
Providing an updated answer because this is still a top result when trying to implement biometrics with CapacitorJs
did you found any solution to this so far? I think your own problem is how to recognize a user? there is actually how I used to do this in react native. First of. you need to have some kind of extra "local storage key" that stored values or user credentials when they log in through the inputs. keep in mind that you are not clearing the "key" even if the user "log out" of the app. so in that case. before they could be able to use biometrics users need to sign in the proper way with the inputs so you could save their credentials like email or any unique values or whatever to use later.
Now, my problem is all the functions are not even working for me ah. it keeps saying "method not implemented"
Post LinkedIn changes (around May 2015) have disabled our use of the share feature, via API call using the URL http://api.linkedin.com/v1/people/~/shares?format=json. We are now receiving a "403 authorization failed".
Steps taken to rehabilitate our share function:
Confirmed that ClientId & Client Secret keys are still the same as being used in our app
The Default Application Permissions have been confirmed, w_share is selected...which used to be rw_share (no longer available). Other selections made are r_basicprofile, r_emailaddress, & rw_company_admin...which are seemingly not related.
Authorized Redirect URLs are still applied for the domain we are using our application under.
Content type has been set to "application/xml", as suggested by other postings.
We have tried for months...hoping that any post changes to LinkedIn would have resolved our problem, yet nothing we have researched has helped. We figure that this might be a glitch from the permission modification update done by LinkedIn...since our code has never change, yet has worked for 2+ years prior to the May 2015 changes.
We would appreciate any insight as to what is going on here....as we are continuing to have this problem.
I found the problem, it was because the security of Linkedin changed. We had to had to alter the statement:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Ssl3;
to this:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls;
If you are relying on the "default application permissions", you may also want to double check that your OAuth code is not still requesting the old (no longer available) member permissions (e.g. rw_nus) via the ?scope= URL parameter, which will trump the "default application permissions" settings you've defined in your LinkedIn app's config.
Otherwise, the w_share permission should still be providing you the ability to post a share to LinkedIn.
I have a Facebook canvas app. I am using the JS SDK to authenticate the user on the browser-side and request various information via FB.api (e.g. name, friends, etc.).
I also want to persist some additional user information (not held on Facebook) to the database on my server by making an ajax call:
{ userFavouriteColour: "Red" }
To save this on the server and associate with the correct user, I need to know the Facebook uid and this presents a problem. How do I pass the uid from the client to the server.
Option 1: Add uid to the ajax request:
{ uid: "1234567890",
userFavouriteColour: "Red" }
This is obviously no good. It would be trivial for anyone to make an ajax request to my web service using someone else's Facebook Id and change their favourite colour.
Option 2: On the server, extract the uid from a cookie:
Is this even possible? I have read that Facebook sets a cookie containing the uid and access token but do I have access to this cookie on my domain? More importantly, can I securely extract the uid form the cookie or is this open to spoofing just like option 1.
Option 3: User server-side authentication on the server:
I could use the server-side authentication to validate the user identity on my server. But will this work if I am already using client-side authentication on the browser? Will I end up with two different access tokens? I would like to make FB.api requests from the browser so I need the access token on the client (not just on the server).
This must be a very common scenario so I think I'm missing something fundamental. I have read a lot of the Facebook documentation (various authentication flows, access tokens, signed_request, etc.) and many posts on SO, but I still don't understand how client-side authentication and server-side authentication play nicely together.
In short, I want to know the user's identity on the server but still make requests to the Facebook api from the client browser?
(I am using ASP.NET and the Facebook C# SDK on the server)
EDIT: Added bounty. I was hoping to get a more deifnitive, official recommendation on how to handle this situation, or even an example. As said, I have already read a lot of the official FB docs on authentication flows but I still can't find anything definitive on how client-side and server-side authentication work together.
Option 1:
The easiest way I can think of is to include the accessToken in JS and pass it with the ajax call.
Option 2:
Using the same as option 1, but instead of sending just the accessToken, send the signedRequest.
On the server side you can decode it using (TryParseSignedRequest method) which will give you the UserID :-)
Note: signedRequest is encrypted with the application Secret. you are the only one who should know it, so you are safe on that end.
Disclaimer:
I have no coding experience in C#, but a little search in google gave me this:
Facebook C# SDK for ASP.NET
Making AJAX Requests with the Facebook C# SDK
It's very simple actually.
When the user loads you app use the server side authentication, get the access token and load the user data by issuing an api request from the server.
On the server side you'll have everything you need and it's sandboxed.
When the page renders for the user, using the js sdk get the user authentication data, you should be able to use FB.getLoginStatus since the user already went through the server side authentication.
Now on the client side you also have an access token which you can use to get the user data from the graph api.
The two tokens will be different, and will also have different expiration, but that should not be a problem, both token should work properly as you'd expect them to.
Since both sides have their own token and a way to make requests to the api, there's no need to send any fb data between them.
So the 3rd option you mentioned, to me, sounds the best, and it's really simple to implement that too.
Edit
All facebook SDKs are just wrappers for http request since the entire fb api is made on http requests.
The SDKs just give you easy and shorter access to the data with out the need to build the url yourself (with all the different possible parameters), make the request and parse the response.
To be completely honest, I think that stop providing a way for the C# SDK to support server side authentication is a very bad decision.
What's the point in providing a SDK which does not implement the entire api?
The best answer to your question, from my experience, is to use both server and client side authentication, and since the C# SDK does not support it, my advice to you is to create your own SDK.
It's not complicated at all, I already implemented it for python and java (twice), and since you'll be developing it for your own needs it can be tailored for your exact needs, unlike a public SDK which should support all possible options.
2nd Edit
There's no need to create a completely new SDK, you can just "extend" the ones you're using and add the missing parts that you need, like sever side authentication support.
I don't know if it's language specific but using both server-side and client-side authentication does no harm.
You can work on option 2 but yes, that will be also vulnerable to spoofing.
Doing option 3, you will be having a single access token for that user session, so that would be the best choice according to me since you always have chance of spoofing when passing user information from client side.
I had exactly the same question recently. It's option 2. Check this post from the Facebook blog.
To be honest I am not enough of a hacker to know if you could spoof the UID in the cookie, but this seems to be the 'official' way to do it.
EDIT: to the other question under option 2, yes, I believe you have to access this cookie on your domain.
is there a way to fetch the venues search in iOS without the user entering his password or showing some foursquare oauth website?
I don't think that this oAuth makes any sense for this kind of request, it should be just an REST api like so "https://api.foursquare.com/v2/venues/search?ll=-27.58818,-48.523248&client_id=JN00ABQBOCK5V54FQ1TWQFLOOIDU12UAZXURHXGXNK0ESJBY&client_secret=14ES1NXTCL1XC5HSLBUT4LWE4ROEDGNYKKWGGERZQGUKQ5JC"
but this one is deprecated =/
Any thoughts?
It's not deprecated, you're just missing the "versioning" parameter that specifies what version of the API you're trying to use.
Requesting https://api.foursquare.com/v2/venues/search?ll=-27.58818,-48.523248&client_id=JN00ABQBOCK5V54FQ1TWQFLOOIDU12UAZXURHXGXNK0ESJBY&client_secret=14ES1NXTCL1XC5HSLBUT4LWE4ROEDGNYKKWGGERZQGUKQ5JC&v=20111107 will remove the warning you saw in your response
Add a query string parameter to your request as follows..
&v=20111119 // Choose a proper version.
Update: this is actually a date. So make sure you send current date in yyyymmdd format against v parameter.
According to FourSquare's docs page on venue searching an acting user is no longer necessary:
Some endpoints (e.g. venue search) allow you to not act as any
particular user. We will return unpersonalized data suitable for
generic use, and the performance should be slightly better. In these
cases, pass your client ID as client_id and your client secret as
client_secret. Although the draft 11 of the OAuth2 spec provides a
mechanism for consumers to act via token entitled Client Credentials,
we do not currently support this.
I'm having an issue with Janrain Engage (specifically for the iPhone). I'm using the server-side tokenUrl option to complete my authentication process. To configure this way, I initialize my jrEngage object like this:
self.jrEngage = [JREngage jrEngageWithAppId:appId andTokenUrl:tokenUrl delegate:self];
Since I've specified a tokenUrl, the Janrain library automatically posts the one-time auth_info token to the URL I've specified. My server then uses this token to request the auth_info data from Janrain. I'm using the Janrain example code to make this tokenized request from my PHP server.
For some reason, this works fine when the "One time use auth_info tokens" setting is off. When I turn it on, however, I get error code 2 "Data not found"... I want the security of the single-use tokens. Have I already used the token somehow?
Note: I can see that the SDK is indeed passing the token correctly to my tokenUrl, so that doesn't seem to be the problem.
If it matters, I'm using the CodeIgniter framework on the server side.
Thanks,
Steve
Steve,
Token URLs used with the iOS library (or the upcoming Android library) require multiple use tokens -- the NSDictionary parameter of jrAuthenticationDidSucceedForUser is populated with data gathered by using the token.
Edit:
In May we updated Engage to address this issue, auth_info token URLs for the native mobile libraries no longer require multiple use auth_info tokens.