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... :(
Related
I am not sure this is correct SO to post on, but if not admin please feel free to move it to relevant SO or suggest me to move it.
I am using a contractor to help me create a website for some project. He has coded the entire custom website in PHP.
One feature that I requested was that links posted on the website should have the preview feature that we see in Facebook (FB) like in attached picture.
But he keeps saying that I can only use embedded code to create such preview feature. When I show him the FB preview he says FB is probably using technology of its own. Currently if I post the link from youtube to my test website it shows up as text like: https://www.youtube.com/watch?v=jtkUtNzaFPI&t=1909s
My question is:
What exactly is FB using? Is this easy to implement for any PHP developer or is it really time consuming implementation.
"he says FB is probably using technology of its own"
His answer to your question is utter nonsense, and indicates only that he doesn't want to do what you're asking. You hopefully aren't paying him very much.
What Facebook is doing is kind of sneaky, but structurally simple. The order of operations is:
User enters text on Facebook page.
AJAX request is sent to Facebook server with text.
Facebook server parses and sees that there's a link in there.
Facebook server makes a server-side HTTP request to link destination to find out more.
Facebook server parses response for anything it can add to the input template that the user is seeing.
Facebook responds back to user (maybe web sockets? maybe a response to that earlier AJAX request?)
Client-side code on the Facebook page updates what the user is seeing.
Steps 2-6 intuitively sound like they may take a lot of network time, but these tend to be very quick services (Facebook itself, YouTube, etc.) so that's usually not a problem.
The main concern here are Step 3 and Step 5. That's where Facebook is using some custom logic that it likely spent considerable effort defining. There may be libraries which help with that, likely made in response to the demand for this exact feature. I don't have any to recommend, sorry.
The technical implementation is the easy part. Determining from the user's text what data to fetch could be difficult. Determining what data to put in the page could be difficult. That depends on the scope of what you want to implement.
For example, it may be difficult to detect if the user has entered a variety of things you can respond to, but it may be easy (with a regular expression perhaps) to detect if the user has entered what might be a YouTube URL. So if you reduce the problem space to just YouTube previews, then you may be onto something. If you can successfully parse that YouTube link, you're in business. Now you can hit a YouTube API and get information to send back to the page.
Continue with that pattern for other small problem spaces (previewing a link to an image, previewing a link for another popular site, etc.), and you can over time add that same feature.
FB, having updated their API to disallow generic shares (Oct 2012), now require us to utilise built-in actions. Moving on from there, we can use Mention Tagging (https://developers.facebook.com/docs/opengraph/mention_tagging/) to allow messages and mentions be created - this is all fine.
However, on the same page above they say "You must also describe step-by-step how users can add/remove tags in your app." - but they neglect describing what call must be made to the API to do so.
Has anyone else done this successfully?
Say I have a user who's mentioned 5 people in an action post. Then say one of them would like to be untagged. I provide them a link to allow them to untag themselves, but what call should be made to the API.
Has anyone got any experience at this? All help appreciated.
Paul G
Say I have a user who's mentioned 5 people in an action post. Then say one of them would like to be untagged. I provide them a link to allow them to untag themselves
I don’t think you have to offer a link for tag removal to the other users that have been tagged by your user. Standard FB functionality through the facebook.com UI should enable them to do that already.
It does not make much sense to me to offer such links on your own to people that have been tagged by your app’s user, but might not even be using your app themselves. (To ensure that they are legitimately requesting to be un-tagged, you’d have to identify them first – by having them connect to your app. I don’t think that’s how Facebook want it to be.)
To me, the intention of the guidelines is more to ensure that you are building a clearly understandable UI for your app, for the process of the user entering his message. If they start to type #PaulG, and you want to “translate” that into a tag, f.e. by highlighting it in the text edit box like it happens on facebook.com, then it a) has to be absolutely clear to your user, that they are tagging someone this way, and b) you have to give your user a way of removing that tag right there and then (before posting his message), in case he does not want to tag a user, but just have the characters “#PaulG” stand for themselves in his message.
I'm designing a simple web app for some elderly family members, 1 of whom has Alzheimer's. The end goal is to provide them each with a tablet (probably Android but irrelevant for this problem) that would be stripped down to ideally 1 bookmark on the home screen which opens my web app.
What I am looking for are ideas on how to identify the user without the conventional username/password methods. With their condition I know that remembering an username is going to be almost impossible, let alone a password. Ideally I would recognize the device and relate that to a specific user.
There will be other users on the app that access it through normal methods (username+password on PC/mobile/tablet), which I'm handling with Zend_Auth. It's just these 2 users who I am concerned about identifying.
Security isn't a huge concern as the data will not be sensitive in any way, but I still need to differentiate between users.
I am building this in php with Zend Framework. I'm really looking for more ideas than specific code, although anything based in php or javascript would be great. Any ideas or suggestions would be greatly appreciated. Thanks for your help
These advice are only valuable if security is not an issue :
On the bookmarks page, insert a token in the link, which you will use to authenticate the users.
if you can, check in the background for IP/user agent (if there is only one device that needs this simplified auth process, and assuming it's connection uses a fixed IP address)
And a simple idea if you have multiple users using the same device :
on your bookmark page, put a picture of each user
make it clickable, with the token discussed above in the href of the link.
That's simple to implement and easy to remember.
Hope that helps !
This is not duplicate, as it may seam from the title. Continue reading.
So what I want is to create JS script, which would automatically send an invitation to a certain user to become a friend.
How do I approach this?
Basically, user will need to copy my JS code to browser URL bar, which will append JS directly to the Facebook session. (meaning that now I can send POST request on behalf of the user)
Of course, users are aware about the final result. (it is sort of blind-dating what I am thinking to make)
Is this theoretically possible?
Edit: I think the best way to implement something like this is to use Facebook Connect to authenticate users on your site and connect the users that way. Once the users have connected on your site, invite them to connect on Facebook too (by using the method below or just linking to their profile). This way, you're controlling the "meet", like you want, but you're also allowing them to connect on Facebook in a legitimate way.
Give this dialog a shot, and just direct the user to:
http://www.facebook.com/dialog/friends/?id=<USER_ID_TO_BE_ADDED>&app_id&<APP_ID>&redirect_uri=<ADDRESS_IN_YOUR_DOMAIN>
Alternatively, you could simply open a popup with that URL using window.open.
From what you suggested in your question though, it doesn't sound like you wish to use the feature like Facebook intended. From the usage notes:
This feature is intended to help users become friends on Facebook with people that they are connected to in real life. You should not use this feature to encourage users to friend other users that they are not connected to in real life. If your app is found to be encouraging this behavior, your usage of this feature may be disabled.
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.