I'm developing a standalone website application that makes use of Facebook Connect and the new Javascript SDK that was released in June.
I've been trying to get friend invites working. I'm able to send an invite using a request dialog (http://developers.facebook.com/docs/reference/dialogs/requests/), but the URL that the user clicks through to when they accept the invite is the internal Facebook app page (http://apps.facebook.com/APP_ID/?request_ids=REQUEST_ID&ref=notif), not my site URL.
Is there any way to fix this so invites work with FB Connected web applications?
It seems this was possible with previous versions of the SDK.
I have seen some posts recommending a redirect from the canvas page, but I have also read that this can lead to the application being suspended by Facebook:
http://forum.developers.facebook.net/viewtopic.php?pid=343257#p343257
Many thanks for assistance on this matter.
I would never expect Facebook to lead me to an external URL by accepting an invite via the request system - especially when most invites/requests tend to be spam.
Have you thought of distributing your invites via the Facebook Message system or sending them via email instead?
This would make the whole process a lot less misleading to a user.
Related
What is the difference between using Google OAuth and signing in users at the frontend of the application, and signing in users at the backend side of the application?
Example: Signing in users and getting the ID and a auth object in React or letting Node/Express handle everything, the prosess, redirecting and store it in a database.
Is there any advantages for one or the other methods, which are most common and are there any "rules"?
What is the difference between using Google OAuth and signing in users
at the frontend of the application, and signing in users at the
backend side of the application?
So to clarify to everyone reading this, signing in users at the backend side of the application is another way of saying OAuth for servers and signing in users at the frontend of the application is OAuth for JavaScript browser applications such as React.
Signing in users via OAuth for servers and browsers results in a 'token' that a server/browser can use to make requests on behalf of the user. We are asking the user to provide us access to their information via an outside service provider such as an email address, identification of some sort and it will be inside that token as well as some possible permissions that allow us to take actions on behalf of that user.
Is there any advantages for one or the other methods, which are most
common and are there any "rules"?
Server-side OAuth is usually used when we have an app that needs to access user data when they are not logged in. So if you are attempting to build an application that needs to access the users email every ten minutes and possibly delete emails on the users' behalf, you would want to be able to access their email account every 10 minutes regardless of whether they are logged into our application. So for this use case we want to make use of Oauth for server.
Otherwise, if we are not trying to do anything on behalf of the user except sign them into our app, then we can just go with OAuth for browser.
Those two things are very different. Without knowing the specifics of what you're trying to accomplish, you should know as a general rule that front-end-only authentication and authorization leaves you extremely vulnerable.
If someone knows JavaScript well, or is using editing plugins, or any of a million different things, they can bypass much front-end authorization. Or they could just watch to see what calls your app makes to the back end, then simulate those calls from something like Postman, bypassing your web front end entirely.
If you're not securing your backend, you're not secure. Typically systems do both.
It is just a different ways of registering users to our website.
Signing in users at the frontend using OAuth can be very handy as it enables our users to not go through our boring forms in our website. Using OAuth is just one click away from registering users in our website. Beneficial to both the clients and developer.We are provided with the general information about clients by the provider(google,facebook) just clicking on one button.
Signing in users at the backend side is the traditional way of registering our clients. Here we force our client to fill the forms in our website(which may be painfull if it is a long form) and all the filled data is stored in our database.
So they are both different ways to register clients to our websites. Both are used very often. It depends on usecase and needs. Oauth can be used if you want to attract more clients by registering them just by one click.
I have been making web applications for around 4 years now, and I have always had troubles setting up the Facebook web SDK.
But for my new application I really wanted to make the Facebook integration.
The problem I am facing now, is that I am using the JS SDK witch was fairly easy to set up, but now I want to build my backend to support it all. The flow I came up with was like this:
The user logs in
The user giving me their FB-id
A call from the back end create the new profile or logs if its a older user
The api gives back a api key for the other requestes.
The problem I see with this flow is, that if another person haves another users facebook id, they can obtain a api key for that user, just by sending the request with that id to the server.
How can I make this secure. I don't really thing that the docs on facebook are great, and the other tutorials on the web dos not cover this topic.
Thanks for the help guys!
I am building a Wordpress website where there will be users who are clients and users who are specialists in a specific area that can be hired for a service by the clients. The owner wants the clients and specialists to be able to live chat with each other, there is no interest in having the users talk with the owner or a bot like you see with many sites using Facebook Messenger. Can the Facebook Messenger API handle this user to user messaging? They will be logged into the site using the Facebook login and their accounts are linked to their Facebook account. Or is there another tool that could handle this that I may not have thought of?
There is no official way to act on user's behave. But here is a workaround: https://github.com/Schmavery/facebook-chat-api
This API is the only way to automate chat functionalities on a user account. We do this by emulating the browser. This means doing the exact same GET/POST requests and tricking Facebook into thinking we're accessing the website normally. Because we're doing it this way, this API won't work with an auth token but requires the credentials of a Facebook account.
Quick short background
I'm building a standalone web app using Angular JS 1.5. This web app makes usage of a API built with Laravel 5.2 (no sessions, just JWT Tokens and REST calls). Using Laravel-Socialite, I managed to make the following structure. It works nice and all, but we kind of have a overload of redirects.
The Button calls a /facebook route that invokes the Socialite magic box which leads to redirect to the Facebook Page for authorization.
After I achieved this, I noticed that a Facebook Login LOOKS a lot more of a front-end task than a back-end one. It's just about helping the user quickly sign up using Facebok available data or sign in without a password.
The Problem
Socialite makes usage of my Facebook App Secret, not to mention that it's a known environment server operation, while a Front-end we may never trust. Here is what I managed to achieve using JavaScript SDK (with AngularJS).
On a first-time access, I can get that information and sign up the user and automatically sign him in. But the problem lies on a existing user.
In this case, technically I can use the response.email information that Facebook gave me and make a request to my API to make a login without a password. But can I really do it? How do I make sure the request is being made because Facebook authorized it? After Facebook replies to my Web App, what is a secure way to tell my server that it can issue a JWT Token to that email?
Conclusion
Do I make the three-step redirection (Web App → Server API → Facebook) to sign in / authenticate a user using Facebook or is there something I'm missing here that could be the key to transferring this responsibility to the front-end (and avoiding a 3-step-redirection)?
I am working on a site that will allow users to create an account. Then website developers will be able to integrate that authentication system into their site and allow users to login with my sites login credentials. I am wanting to do it similar to the way facebook connect, Google, twitter, Microsoft works.
I have researched alot about this and discovered "Oauth2" which I think is what I need. But I'm not sure about how to use it anyhow. I have downloaded two libraries of oauth2 (Php(server) and Javascript(client)) but don't know where to start.
I simply want functionality where developers create a button which when clicked will send a request to my server and get the user's (who is currently logged in $_session) information from my server database and send it back to the third-party(the developers) client page.
Problem is Its not possible to send session data from server.com to client.net using simple Ajax requests. So I thought oauth2 might be problem to my solution.
So what is it can anyone help me out?
I have already read few of tutorials on oauth2 and nothing suits my needs. So it would be great if someone can show a little working example.