Summary: We're not. This was dropped during the port of the iOS implementation. Thanks to Karsten Sperling (https://github.com/ksperling) for reporting. Test Plan: modify a sample to change the value to false, and see publish not occur. revert + delete the app & re-test. see the publish occur. Reviewers: mmarucheck CC: msdkexp@, neko-dev@ Differential Revision: https://phabricator.fb.com/D574705 Blame Revision: D559309
…oid lint warnings.
…github. Summary: persumably the XSS code that github runs caused this part of the url to be dropped. we'd rather have the url be clickable with screaming caps so that it's obvious what we're trying to express. Test Plan: none. Reviewers: mmarucheck Reviewed By: mmarucheck CC: msdkexp@ Differential Revision: https://phabricator.fb.com/D560306 Blame Revision: 559309
Summary: On authorize, automatically publish an install attribution if it can be acquired from the installed Facebook application, and the application allows it. If the app does not use Facebook login, they may call publishInstall() directly. In both cases, this code handles tracking success so that reporting should only occur once. Call early, call often for best results. Test Plan: - ant build Hackbook - Ran Hackbook, verified that the publish occurs. - Ran again, verified that the publish did not reoccur. - Modify hackbook to explicitly publish. Saw it work. Revert Plan: safe to revert Reviewers: clang, mmarucheck Reviewed By: mmarucheck CC: msdkexp@ Differential Revision: https://phabricator.fb.com/D559309 Task ID: 1404123
Summary: There was only a single method for setting the access token on the Facebook class (setAccessToken()). This did not distinguish between setting a token loaded from cache vs. setting a new token resulting from authorization. Since setAccessToken() updates the last-token-updated timestamp, and since this timestamp is used to determine when to refresh the token, it always looked like the token had just been updated when the app's Activity started. This meant the Facebook class would never try to refresh the token. To fix this, the Facebook class now supports getting the value of the last-token-updated timestamp, and also supports restoring this along with the token value and expiration timestamp in a single operation. This also updates Hackbook to demonstrate caching. Test Plan: - ant build Hackbook - Ran Hackbook, verified that we could get and restore the timestamp. Revert Plan: safe to revert Tags: Reviewers: clang, vijaye, caabernathy Reviewed By: clang CC: msdkexp@ Differential Revision: https://phabricator.fb.com/D552473 Task ID: 1363221
Summary: By default, Android WebViews store passwords in a per-application sqlite database. This changes the default for the Facebook SDK. Test Plan: - Build from command-line. - Uninstall Facebook app, run Hackbook, log in, adb shell, inspect webview database to verify no password was saved. Revert Plan: OK Reviewers: clang, jacl, vijaye Reviewed By: vijaye Differential Revision: https://phabricator.fb.com/D497389 Task ID: 1108189
Summary: To give credit for changes, I am listing author/pull request here for changes incorporated in this checkin. I am submitting these changes directly to master to preserve a linear history, to allow for minor edits, and to credit multiple people when more than one change was merged to fix a single issue. === Summary by submitter of pull requests in this commit === andypalmer: - 160: ClassCastExceptions in Util.java grant land: - 216: Fix ArrayOutOfBoundsException when clicking "Don't Allow" in FbDialog one iamnoah: - 117: Fixed a NPE lvillani: - 261: Add support for Android build system. nikreiman: - 218: Fix exception when trying to decode invalid string plowman: - 246: Fix for Issue #160: ClassCastExceptions filling up the logs. To investigate pull request 260, I enabled orientation changes in Hackbook. This did not demonstrate the issue, but doesn't hurt anything and makes it easier to test on the x86 emulator. I also fixed some build issues in Hackbook around SDK version required and the path to the SDK. Test Plan: Full clean builds of facebook and Hackbook. Verify creating Eclipse project per public docs still works. Upload photo in Android Hackbook. Reviewers: caabernathy, jacl, vijaye, yariv Reviewed By: jacl CC: ekoneil, gregschechte Differential Revision: https://phabricator.fb.com/D451434 Revert Plan: Safe to revert Task ID: 1028564
Summary: We need to call unbindService on a Context. In some cases, mAuthActivity is null. Since applicationsContext is passed in to the constructor and never modified, it should not be null. So we call unbindService on applicationsContext instead. Test Plan: Try SSO with pre-1.8 FB app. Reviewers: vijaye, jacl, caabernathy Reviewed By: vijaye CC: selekman, constantin, lshepard Differential Revision: https://phabricator.fb.com/D432892 Revert Plan: Safe to revert Task ID: 982981
Summary: Logging was turned on unconditionally before, which led to apps leaking sensitive data. This change puts the logging api behind an explicit gate that developers have to turn on. It's unfortunate that this isn't automatic - ideally this would automatically turn on for non-release signed bits. I couldn't find such a check in Android framework. If android experts have better ways of tackling this, i'm all ears. But bear in mind this is a security fix and needs to go out asap. Test Plan: Launched in default mode and verified no logging in emulator. Turned on log gate and verified logging. Reviewers: mmarucheck, lshepard, yariv, raghuc1 Reviewed By: mmarucheck CC: gregschechte, jacl Differential Revision: https://phabricator.fb.com/D411377 Task ID: 933141
Summary: The TokenRefresh intent is exposed as a service, but we were validating it as an activity. Fixign that and refactoring code. This code should have never worked. Note that without the FB app the refresh token feature will not work. If that is necessary, it's not part of this diff. Test Plan: Verify that hackbook can login & refresh token on the emulator. Reviewers: mmarucheck, yariv, ttung, raghuc1, trvish, pfung Reviewed By: mmarucheck CC: gregschechte, jacl, lshepard Differential Revision: https://phabricator.fb.com/D410960 Task ID: 926377
Summary: This allows developers to silently refresh their access token by calling Facebook.refreshToken method. This SDK will try to call our Facebook Android App which will handle the API call. Test Plan: This requires adding a refresh token service to our sdk. See D364973. After that try using the new Hackbook example. Reviewers: jimbru, raghuc1, brent, dalves, ttung, yariv Reviewed By: jimbru CC: dalves, jimbru Differential Revision: https://phabricator.fb.com/D366540 Task ID: 799996
A failed feed post returns those (there may be other endpoints that use them).
Summary: There are two types of access tokens: - ones that doesn't expire (expiresIn == 0) - ones that have some expiration period( (expiresIn > 0) When we receive a new token from FB server for both them we call the setAccessExpiresIn method. Because of that: 1. We shouldn't ignore the "0" value 2. We should also expect tokens that have long expiration period. For example 60 days is 2592000000000 miliseconds which is too much for an integer variable to handle :) Test Plan: Tried Login In / Logout for both types of tokens. Reviewers: jimbru, yariv Reviewed By: jimbru CC: kamil, jimbru Differential Revision: 370353
Summary: Cleaning of the Hackbook code. Main reason of this commit is mixing tabs and white spaces inside the code, which makes the code ugly (for example browsing the code inside github). In addition I also refactored few other things: - I tried to wrap the lines to 100 characters per line (80 per comments) - at least in those places where it made sense - Remove trailing whitespaces and unnecessary blank lines - Add missing @Override adnnotations - Fixed syntax in some places (like "for(i=0;..." -> "for (i = 0;...") - Added missing 'static' keywords Test Plan: Run the app and see if everything works :-) Reviewers: jimbru, raghuc1, vksgupta, dalves Reviewed By: dalves CC: platform-diffs@lists, nbushak, dalves Differential Revision: 370079
Summary: This is the android sdk side of D340841. The hope is that developers will be able to take the key they passed in and past it into their application, thus skipping the necessity of having keytool and openssl. It also reduces frustration. Test Plan: This requires a change to our sdk :-/, which currently dosn't show error descriptions. Anyone know how I can push a change to the git repo? We start with non-useful error message. After applying this and the sdk change, we get the message https://our.intern.facebook.com/intern/pixelcloud/image.php?id=31789 after pasting in our key from the message, sso succeeds https://our.intern.facebook.com/intern/pixelcloud/image.php?id=31787 Reviewers: yariv, jimbru, ahimel, brent, lshepard Reviewed By: jimbru CC: platform-diffs@lists, ptarjan, naitik, rhe, jimbru, yariv, lshepard Differential Revision: 341355 Revert Plan: ok Platform Impact (PUBLIC): Android SSO invalid_key failures will now contain the key that developers attempted to use. If this key were to be copied directly into the application settings, SSO will work properly for this application. This makes it so that developers never have to mess around with keytool/openssl. They can just attempt a request with a dummy string, then use the error string returned by our endpoint.
Summary: The sample app includes SSO, feed and apprequests dialogs, get friends via graph or fql, post on friend's wall, get nearby places and check-in to a place, upload photo from local media gallery or remote server and Graph API Explorer Test Plan: The sample app can be downloaded from: https://developers.facebook.com/attachment/Hackbook.zip. Try it out and lmk if code can be optimized or other changes. Reviewers: lshepard, mattwkelly, dkim, dlim, caabernathy, omids Reviewed By: dkim CC: platform-diffs@lists, nbushak, vksgupta, ccwu, erling, dlim, dkim Differential Revision: 325685