This could be me making extrapolations from the documentation (which given how it's organized, isn't too difficult to do) but did Facebook make some big changes to how application developers create and utilize test users?
To my recollection (and I last did this about a month ago), developers used to be able to go to a url from within a logged in account that would convert that user to a 'test user', who had no privileges in the public system but could serve as a test entity for publishing, getting permissions, etc. I had a test user setup via this method and had generated access tokens for him/her that were saved to the database.
Recently this all stopped working. My first instict was to print out the properties of the Facebook object I had created, and where once there had been the JSON decoded user data, there now was an exception from the CURL process that accessed the /me/ api endpoint.
Facebook GraphAPI – Uncaught EntCannotSeeExistenceException: The entity (class EntTestUser) backed by id 12345 cannot be seen by the current viewer 12345 (EntID: 12345)
Values obviously changed to protect the innocent. The userids were identical however, which made it strange that the user possessing ID 12345 for some reason had no rights to see 12345
I looked through the Facebook documentation and found their what seems to be their new logic for making the application itself create temporary test users and generate login URLs for them, something alot of people here are probably familiar with.
http://developers.facebook.com/blog/post/429
Has this system superceded the old one? It seems that acting on behalf of test user accounts generated via the old method is no longer permitted since they are not made "by" the application. I wrote some quick logic to test this new process with fixed access tokens and it worked - I should also mention that all the application logic functions as it originally did with no errors for real user accounts. Has anyone else experienced this with their Facebook api apps? Can we definitely say that these old access tokens/userids/accounts made via that old method are now effectively useless?
Thanks as ever.
http://developers.facebook.com/blog/post/475
I hate to break form and answer my own question, but from the comments enough people seem to be having this problem.
Digging through the developer updates today I finally found the above post (having already written workarounds, of course) Quoted:
We have removed the ability to turn
user accounts in test accounts as
mentioned here to prevent
unintentional conversions of real
accounts into test accounts. The
proper way to create test accounts is
by using the accounts connection of
App Graph Object.
This tiny notification was mixed in with the updates for March. Probably should RSS their developer blog so these things don't take me by suprise again! This particular update became effective March 4th. In any event, it's good to have a conclusive answer right from the source.
Related
There's one news-portal and its huge (site A). During production backwards, it has been even powered with some sort of a social networking stuff - not yet started, but about to start (soon site B).
Packed together looks great, but in some future there might be a lot of problems with maintaining the database, servers and stuff so I've been asked to separate it as I did. Site A goes on its own domain, site B also - databases are separated.
Now, I need to do the following: when user logs into site B (social site) and arrives to site A (portal) they should be instantly logged in there too (on a site A).
Any ideas how to do this - without duplicating entries to user tables?
EDIT:
Any other ideas instead of auth services? OpenId will just give us one user with 10 accounts, fakes and so on. How about cookie stuff or multi-database queries?
EDIT 2:
Well this is something hot.. unless its not April 1st joke and worth a try:
http://www.shawnhogan.com/2005/12/cross-database-join-with-mysql.html
You can use OpenID.
OpenID is an open standard that describes how users can be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities.
If you want to share some profile information (e.g. posts or photos) without giving access to your login and password you can use OAuth.
See if my answer here is of any use.
It's pretty simple, and only requires user information to be kept on one side. Where you need some information on the non-database side, you can just pass that information there using values in a query string, alongside the encrypted string.
Can you believe this?
$DB->query("SELECT * FROM table..."); // works of course...
$DB->query("SELECT * FROM another_database.table..."); // WORKS ALSO!
This guy is a miracle:
http://www.shawnhogan.com/2005/12/cross-database-join-with-mysql.html
I don't believe it, so simple at the end!
I'm using the server-side SDK to access Facebook Authentication.
After authorizing my app - even with the included example.php, I can go to App Privacy in settings then click on the app, then See Details in the Last data access section
And the dialog shows:
My App accessed the following information on your behalf:
Basic Information - Today
Likes, Music, TV, Movies, Books, Quotes, About Me, Hometown, Current City, Education History and Work History - Today
My Friends' Current Cities - Today
All I really need from the authentication is the userid and possibly name... I don't care about any other personal info. And yet even the example.php which is really basic seems to be requesting a lot.
Is there another way to authenticate without Facebook thinking I pulled all this data? I don't want users to be concerned about excessive data pulling when I'm not even pulling it.
The Stack Exchange authentication does not have this issue. It might be an issue in the PHP SDK?
The additional entries in the app access log are created for requests to the /me-object without a fields-parameter. So instead of accessing /me?access_token=xxx use /me?fields=id,name,...&access_token=...
Please note that the access log is not deleted when you remove an application. This may be quite confusing during testing because you will see old entries.
Suppose you're developing an independent, small sub-page for a big and well frequented web portal.
The sub-page shows entries from a public event calendar, and allows users to highlight those especially interesting to them. The highlighted events shall be highlighted (and maybe shown on a separate list) on each future visit of that user.
However, building a classical user registration system, or any other way of storing the user-highlighted event picks on the server, is not an option: The sub-module needs to be as self-contained and need as little maintenance as possible. It's one of the conditions of the project.
The only way to do this without building a login system of some sort (as far as I can see) is using cookies or some other local storage (Flash / HTML 5....) which has the obvious and big downside that it's tied to the computer, not the user.
Is there a way of storing a few kilobytes data on a per-person basis, but without having to utilize a login or openID, that I am overlooking? A reliable web service perhaps?
A "key/value" storage service, to which I pass a unique key (one that the user specified) and get the savedvalue in return, would be sufficient. There is no need for real security - the data in question is by no means confidential.
OpenID is not an option: It is not well known enough among the audience of the site.
Facebook would be an option, but I don't think they provide "storage" options like this.
As a workaround, I am contemplating offering the user their event picks as a text file download, that also can be uploaded and turned into cookies on another machine. But that is pretty complicated for the user, and thus not perfect.
We have a similar system on our site, where users can bookmark pages to a planner/wishlist function. The saved items are sent via a webservice and stored on our server, and there is a corresponding get webservice.
We have a 'lazy register' system. The first time a user saves an item, they are asked for their email (but no password, as nothing is confidential). This is hashed and saved locally using a cookie, then used to set/get the saved items. When the user uses a different computer they are again asked for their email.
The key is that a register and a login are the same operation, so there is no need for any password reminders or any reset functionality.
The Google Docs API provides programmatic access to Google Docs, where you can create and store documents and spreadsheets. Your application could have its own Google login, which it uses to create one or more documents per user. These documents could be used to store the user settings.
Provided you can get a unique ID from each user (an email address, or something more secure, perhaps), this should be fairly simple. You can even organize the files into folders—one per user.
Alternatively, you could combine Google Docs with the Google Spreadsheets API, where I have just noticed this rather handy feature:
Tables & Records
Interact with spreadsheets as if they're a database
using Tables and Records.
Here's the deal:
-Flair pretty much demands a Facebook app
-I'm working on learning the Facebook platform
Therefore, I've written a dinky little Facebook app to embed your Flair into a box on the side of your profile. If you're interested and on Facebook; beware that this is very much a work in progress, prone to change and has a whole bunch of rough edges.
However, I don't have an elegant way to say "this is MY Stackoverflow profile" from this dinky app. My current solution is best demonstrated this image. It is, frankly, idiotic; and there's nothing preventing impersonation.
Having no experience with OpenID, I'm wondering if there's some way (and some example of this way, please) to get a user to provide their Stackoverflow identify to a third party?
Behavior changed to that suggested by Noldorin's answer.
Request for a saner way to do this declined on UserVoice.
There's no way to get a StackOverflow ID from OpenID and to do the opposite would be possible but unnecessarily complicated (compared to your suggested method). Copying and pasting the user ID/profile URL isn't terribly inconvenient, in my mind.
However, I can suggest some sort of solution to the issue of impersonation. This may seem like a slightly silly method, but it's the simplest way of which I can think to insure that only the user themself can display the badge. Again, I don't think it's too inconvenient. (The more traditional method of using an email confirmation isn't possible, given that emails aren't public.)
Have your Facebook app generate a random (alphanumeric?) code. Something in the form A8IO45QW6T should do.
Hold this code on the server side of your Facebook app for a short time period (say, 5 minutes).
Instruct the user to edit their About Me information by adding the given code to the last line, then to return to the Facebook and confirm. Simple inspection of HTML for the profile page of the specified user would verify ownership. The user can then remove the verification code from their About Me text.
Nice idea creating this Facebook app, by the way. I may just give it a try!
Another solution that would allow for instant verification is hashing the email address and checking to see if it matches the user's Gravatar. Granted, not every user has provided an email address, but you can always perform this check first and if it fails you can fall back to the About Me section editing (or simply require that the user have an email address). This idea is not mine, so I'll let null explain:
Do you still have the source available? As I've gotten a solution to prevent other users from messing up your results. You just need to hash the email address used by the viewer and check for the gravatar image link on the page as outlined on the gravatar site. If the user id and image hash match, then record the change to the database, otherwise... just show results. I can make that change, but the source seems lost... :(
I developed a simple application on Facebook using PHP and I want to know how the people can add this application, and after adding the application a update is generated (e.g vipin join this application).
Thanks
Users don't add applications anymore. The closest they can get is bookmarking, which your application receives no notice of. The closest thing you can get to checking as a developer is checking is Users.isAppUser.
You also don't receive notice when a user grants/rejects permissions (which is generally a prerequisite to viewing your application).
Basically, you have to post notices and create feed entires in direct response to user action (unless they've granted you a perpetual session).
The old model of actually adding applications was all kinds of broken from a user experience point-of-view, so Facebook basically pulled the plug on it.
Yup, no more "Dude just added this app" messages in the newsfeed. However, Facebook will occasionally show "Dude uses the 'Thing' application" messages under the "highlights" section of a user's homepage. There's nothing you can do to encourage or discourage it -- it just happens.