Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can not use a lot of the Graph API #2

Closed
cstromme opened this issue Aug 15, 2010 · 14 comments
Closed

Can not use a lot of the Graph API #2

cstromme opened this issue Aug 15, 2010 · 14 comments

Comments

@cstromme
Copy link

Been testing a few things with this new SDK the last days, and there are several parts of the Graph API that doesn't seem to work. As an example doing:

[facebook requestWithGraphPath:@"app_id/likes"
                   andDelegate:self];

Just returns an empty dictionary from the server. Replacing app_id with the actual numeric id of the app. Also doing "album_id/photos" returns an empty dictionary.

Am I misunderstanding something, or is there something wrong with this library?

@cstromme
Copy link
Author

user_id/posts works, user_id/albums just gives me an empty result back, user_id/friends gives me an error ("Failed: Error Domain=facebookErrDomain Code=10000 UserInfo=0x5a68350 "Operation could not be completed. (facebookErrDomain error 10000.)"").

@lshepard
Copy link
Contributor

If you want access to a certain type of data, make sure to ask for the permission in the authorization flow. Read this for more info:
http://developers.facebook.com/docs/authentication/permissions

However, for the "operation could not be completed" error, can you give the parameters you're calling with (including user ID, app ID, and the graph path)?

@cstromme
Copy link
Author

Graph-path: 846525646/friends
App-ID: 122315137816686

User-ID of the one doing the call?

Any chance you could give me a short example of how to "Like" an application? And how to post to your wall an ad for the given app?

@cstromme
Copy link
Author

Also I have added every type of permission to the authorization:

NSArray *permissions =  [NSArray arrayWithObjects:@"publish_stream", @"create_event", @"rsvp_event", @"manage_pages", @"user_about_me", @"", @"user_activities", @"user_birthday", @"user_education_history", @"user_events", @"user_groups", @"user_hometown", @"user_interests", @"user_likes", @"user_location", @"user_notes", @"user_online_presence", @"user_photo_video_tags", @"user_photos", @"user_relationships", @"user_religion_politics", @"user_status", @"user_videos", @"user_website", @"user_work_history", @"", @"read_stream", @"offline_access", @"friends_about_me", @"friends_activities", @"friends_birthday", @"friends_education_history", @"friends_events", @"friends_groups", @"friends_hometown", @"friends_interests", @"friends_likes", @"friends_location", @"friends_notes", @"friends_online_presence", @"friends_photo_video_tags", @"friends_photos", @"friends_relationships", @"friends_religion_politics", @"friends_status", @"friends_videos", @"friends_website", @"friends_work_history", nil];
[facebook authorize:@"122315137816686"
        permissions:permissions
           delegate:self];

@yujuan
Copy link

yujuan commented Aug 16, 2010

For the "Like", we currently do not have support for that yet. But we are working on that. Hopefully, we can have it in the near future.

@yujuan
Copy link

yujuan commented Aug 20, 2010

This issue should be solved by some recent check in about fix the url encoding.

@petem
Copy link

petem commented Aug 27, 2010

Does this mean the fix for eg "photoID/likes" returning correct result has been checked in at time of writing, ie august 21? Also indeed, how do we "like" something?

@yujuan
Copy link

yujuan commented Aug 27, 2010

Currently we do not have a implementation for Like yet. We are still working on that. Please check back with us on the developer website.

Thanks

@andreaorimoto
Copy link

Hello yujuan, is there an update on this one? Any ETA for this feature? Specifically I'm waiting for the App-Id/likes feature.

In case this is not coming, do you have any good suggestion on how I could work around this?

thanks
Andrea

@yujuan
Copy link

yujuan commented Sep 20, 2010

For App-Id/likes, it is unlikely that we are going to use api to implement that. The reason is that using api is too easy to spam on it. We are planning on something such as dialog. Unfortunately, currently, we do not really have a good way for this feature. The alternative would be use stream publish dialog to publish to user's stream. though it is not a like.

@andreaorimoto
Copy link

Thank you for the quick reply. I see what you mean about the danger of spam, I was hoping in some captcha mechanism or similar. Anyway...

The stream.publish work around does not work (I think), because, unless I misunderstood, I cannot publish to a wall of a user/page/app if the user is not friend (or !Likes) it. This is the whole point of my need. I need to allow the user to "Like" my facebook app so that I can retrieve posts from it and also post to its wall.

I guess I'll need to have my users go and push the Like button on the web. An inevitable extra step at this point.

Any ETA about the dialog solution you were mentioning? That would also work for me.
thanks a lot

@jackbandy
Copy link

I'm having a similar problem accessing info that requires permissions. I request access for "friends_birthday" but when I try to log the date, it shows up as (null). I am pretty sure I am good on everything else because when I try to log something like their name or user ID it shows up fine.

The only birthday I can get is my own. Strange. Anybody figure this stuff out?

@UMAD
Copy link

UMAD commented Mar 28, 2011

I am getting the same error when trying to post just some text to the wall (facebookErrDomain error 10000). By the way, I am just modifying the demo project's publish stream method. Nothing else has changed. Am I doing something wrong?

NSMutableDictionary *params = [NSMutableDictionary dictionaryWithObjectsAndKeys: 
                               @"the api key", @"api_key",@"This is the text of the post.", @"message", 
                               nil];

[_facebook requestWithGraphPath:@"me/feed"
                      andParams:params  
                  andHttpMethod:@"POST" 
                    andDelegate:self]; 

Also, is the api_key the API key or the App ID? I used both of them and still got the same error. Cheers and thanks for any help in advance!

@stuffmc
Copy link

stuffmc commented May 11, 2011

Guys, my 2 cents... Be sure to Modify your application's main AppDelegate - it was my problem. RTFM ;-)

caabernathy pushed a commit that referenced this issue Feb 7, 2012
Summary:
Currently when there is a Platform API call that has any error or if there is a
connection error, e.g. timeout, the access token is invalidated. This was due
to
diff D378197 where any errors call invalidSession. To fix this narrow the
invalidate call to the scenario where the access token has expired when an API
call
is made.

For now, only REST API error codes allow us to easily identify an invalid token
(error code 190). A separate diff will be implemented by the Platform team
to provide an error code for Graph API auth token errors.

Test Plan:
Case #1
1/ Login
2/ Tap Graph API
3/ Tap Get your friends
4/ Go off LAN and WiFi
5/ Tap Get your friends

Case #2
1/ Turn WiFi back on
2/ Tap Get your friends
3/ See friends list
4/ Go back to get to Graph API page
5/ Remove app from https://www.facebook.com/settings/?tab=applications
6/ Tap Get your friends

Case #3
1/ Temporarily modified code to force a Graph API error
     //[[delegate facebook] requestWithGraphPath:@"me" andParams:params
andDelegate:self];
     [[delegate facebook] requestWithGraphPath:@"000000" andParams:params
andDelegate:self];
2/ Tap Graph API
3/ Tap Get your information

Before this change, here were the results
Case #1: Session expires message, which is incorrect behavior
Case #2: Session expires message, which is correct behavior
Case #3: Session expires message, which is incorrect behavior

After this change, here are the results
Case #1: Get the Hackbook "Oops something went wrong" message, which is desired
behavior
Case #2: Get the Hackbook "Oops something went wrong" message, which is not
ideal, user should also be logged out
Case #3: Get the Hackbook "Oops something went wrong" message, which is desired
behavior

Reviewers: yariv, jimbru, brent, toddkrabach, jonathan

Reviewed By: yariv

CC: lshepard, selekman, beau, bgolub, danmuriello, jacl

Differential Revision: https://phabricator.fb.com/D402481

Revert Plan: OK

Task ID: 900407
ghost pushed a commit to WeTransferArchive/facebook-ios-sdk that referenced this issue Mar 2, 2012
Summary:
Currently when there is a Platform API call that has any error or if there is a
connection error, e.g. timeout, the access token is invalidated. This was due to
diff D378197 where any errors call invalidSession. To fix this narrow the
invalidate call to the scenario where the access token has expired when an API call
is made.

For now, only REST API error codes allow us to easily identify an invalid token
(error code 190). A separate diff will be implemented by the Platform team
to provide an error code for Graph API auth token errors.

Test Plan:
Case facebook#1
1/ Login
2/ Tap Graph API
3/ Tap Get your friends
4/ Go off LAN and WiFi
5/ Tap Get your friends

Case facebook#2
1/ Turn WiFi back on
2/ Tap Get your friends
3/ See friends list
4/ Go back to get to Graph API page
5/ Remove app from https://www.facebook.com/settings/?tab=applications
6/ Tap Get your friends

Case facebook#3
1/ Temporarily modified code to force a Graph API error
     //[[delegate facebook] requestWithGraphPath:@"me" andParams:params
andDelegate:self];
     [[delegate facebook] requestWithGraphPath:@"000000" andParams:params
andDelegate:self];
2/ Tap Graph API
3/ Tap Get your information

Before this change, here were the results
Case facebook#1: Session expires message, which is incorrect behavior
Case facebook#2: Session expires message, which is correct behavior
Case facebook#3: Session expires message, which is incorrect behavior

After this change, here are the results
Case facebook#1: Get the Hackbook "Oops something went wrong" message, which is desired
behavior
Case facebook#2: Get the Hackbook "Oops something went wrong" message, which is not
ideal, user should also be logged out
Case facebook#3: Get the Hackbook "Oops something went wrong" message, which is desired
behavior

Reviewers: yariv, jimbru, brent, toddkrabach, jonathan

CC: lshepard, selekman

Differential Revision: https://phabricator.fb.com/D402481

Revert Plan: OK

Task ID: 900407
arminius2 added a commit to arminius2/facebook-ios-sdk that referenced this issue Apr 21, 2012
--Importing in a bunch of .h/.m users for a bunch of people who may have never used cocoa before may not be that obvious.  Additionally, if files are added to the FacebookSDK you now have to go into the sample app and add those.  The solution to something like this is one of two options:
1)  Move to static Framework, but that's kinda tacky
2)  Include the target SDK you're linking against into the project, add it as a dependency, then link against it.

facebook#2 is easy to use, easy to understand, and I just did it.  So that's pretty rad.
facebook-github-bot pushed a commit that referenced this issue May 22, 2021
Summary:
The existing code that was removed was doing 2 things. 1. It was verifying the `request.graphPath` and 2. it was verifying that `loadProfileWithToken:completion:graphRequest:` would be called when `loadProfileWithToken:completion:` was called.

For #1. I moved the code that creates the graph path into a new `graphPathForToken:` method which the existing `loadProfileWithToken:completion:` will call. The test will call the `graphPathForToken:` method directly to get this information (instead of reaching into the `loadProfileWithToken:completion:graphRequest:` method as it was doing before.
For #2. I deleted the code since it really isn't necessary to verify that `loadProfileWithToken:completion:graphRequest:` is called when `loadProfileWithToken:completion:` is called since that's all the method does (after creating the graph path and graph request, so it will always be called). I think it was being verified before just because OCMock needed to call the method anyway in order to grab the request object to check the path.

Also the `testGraphPathForProfileLoadWithFriendsPermission` test was actually verifying the graphPath twice. Once in the method itself and once with the `verifyGraphPath` call which did the exact same thing. Removed the extra check in the method itself.

Reviewed By: joesus

Differential Revision: D28616761

fbshipit-source-id: 41a8a3a0e9ad719382be8de95aafe847eaffdfd3
facebook-github-bot pushed a commit that referenced this issue Sep 1, 2021
Summary: This is diff #2 of removing OCMock from LoginManager. To remove it completely while attaining the same test coverage we need to abstract KeychainStore

Reviewed By: jawwad

Differential Revision: D30683209

fbshipit-source-id: 3f2d31caf5d0209629aee409333944e32abe3684
@devSC devSC mentioned this issue Dec 29, 2023
5 tasks
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants