A requirement to use the RPXNow is to set your Facebook application's connect url to http://mydomain.rpxnow.com.
I was just trying to implement Facebook's Open Graph and I see that it tells you to set the Base Domain to the domain that will contain the app_id.
However, Facebook does not allow these two domains to look different. When I try to set the base url to mydomain.com, I get this error:
Validation failed.
Base Domain is not valid. Connect URL must be derived from your Base Domain.
Should I create two apps - one for use with RPXNow, and another for use with Open Graph? If not, what should I do?
Thanks
The Facebook page regarding Base Domains you linked to states the following:
Facebook Connect stores user credentials in cookies on your application's domain. By default, a cookie set on chicago.citysearch.com would not be readable on sanfrancisco.citysearch.com - the browser treats them as separate domains. If the base domain is set, then Facebook will intentionally set the cookies on the base domain, thus making the cookies readable across multiple subdomains. This allows you to share one authentication session across multiple subdomains.
Note: There is no way to share a cookie across multiple domains. So, for example, if you have a site cnet.com and news.com, then there is no way to make the browser send the same cookies to both those domains. Each of these would require separate API key and separate authentication.
Since your domain and rpxnow.com are different base domains, it seems like you'd need a custom realm (eg. login.yourdomain.com), which is offered from RPXNow at additional cost. You'd probably have to upgrade to "Pro" account (~$95/mo+ ?) or contact RPXNow / Janrain directly and ask them your options.
Related
Want to access data from external service for a facebook application. Not getting a solution on how to do the same.
Facebook apps are iframes inside Facebook. If your application has it's own server-side code, you can access that external service from the server and send the results to the client.
If you don't have your own server-side code, relying on Facebook objects for persistence, than you can access the remote service from the client via JavaScript - but there is a "but". Browsers usually only allow JavaScript to send requests to the domain where the page came from, and obviously your app is not served from the domain of the external service(otherwise it wouldn't be "external"). That means your users will have to set the security options in their browsers to allow access to remote domains - which means you'll have to supply instructions on how to do that, and we all know how good users are at following instructions... Also, having to change security options might scare away some users.
So - if possible, try to do it from your server-side.
I am using Facebook Graph API. To set it up, I need to fill out the App Setting on developer.facebook.com.
I need to specify two URLs, one for local testing (localhost:3000), and another for live app. How should I do this?
Thank you.
I need to specify two URLs, one for local testing (localhost:3000), and another for live app. How should I do this?
That’s not possible – at least not if you want to use Facebook login.
You have two options:
Set up a second app for testing. This works quite well, as long as it does not come to things like Open Graph actions which need to be approved by FB and are tied to the app they were are proved for.
Set your local test environment up to be accessible from your local computer by the domain name used for the live site. F.e. when using Apache as webserver, by setting up a corresponding VirtualHost and manipulate your local DNS into resolving the domain to your local IP (via hosts file under windows). Also since your live app will most likely use port :80, you should set up your local server to answer to HTTP requests on that port.
I'm building a Multi-Tenant application and I'm struggling incorporating a Facebook Login into the web application.
The tenants are using a sub-domain for example
http://tenant-1.domain.com/
http://tenant-2.domain.com/
http://tenant-3.domain.com/
So, I have created an application and when it comes to add the Website, how can I make it to be available in all tenants? Something like:
But of course, that does not work, and if I add just http://domain.com/ it does not work either on http://tenant-1.domain.com/ as soon I click in the <fb:button-login> I get:
How do I do this, without creating a specific FB App for each tenant?
I'm using this to help persons to subscribe their account, I just want the login to get name and email, or they need to fell that up in the name and email boxes...
This is not possible, but there are options to workaround. I think probably the best would be to use a single domain to perform the authentication, specified as the redirect_uri. On this redirect_uri you can append some query parameters, for example your redirect_uri could be:
http://auth.domain.com/auth.php?tenant=tenant-1
Then in the code for auth.php you would grab this tenant parameter from the query string, authenticate the user, store their access token and then immediately redirect them back to tenant-1.domain.com
I'm not sure if this solution will be something you prefer, but it is currently not possible to specify subdomains for authentication, so this or a similar workaround is necessary.
we are looking into implementing Facebook Connect on our wiki service, http://www.wikidot.com. User-created sites span the *.wikidot.com domain, but also custom domains (like mine http://michalf.me), all handled by our single service.
We have a centralized account system. Users always log in (and create accounts) at www.wikidot.com and they are automatically logged in in all subdomains (cookie domain set to .wikidot.com - easy) and custom domains (automatically, via a series of redirects).
We would like to add FC into our login flow. Now, it would be great to get some clarification about FC Terms, which suggests using one App ID for every domain. In our case however user-created sites are not separate applications.
So, is it OK to use FC on one centralized website where our users log in (on www.wikidot.com) and expand user status on other domains connected to our service? This is how it works right now, without FC.
It would be great if we could get clarification from someone from FB to make sure we will not be violating any terms or policies.
Thanks!
It isn't possible (as far as I know anyway) to use the same app ID on multiple domains. FB allows use across subdomains, but I have found some difficultly with this even at times with the cookies. When you set up an app, you are asked to provide the domain for it. The domain you put here is the only domain that your app will work for. If your users are only ever signing in on wikidot.com, then I suppose you can use what you have already to move those sessions onto the other domains, but once you are on the other domain, you won't be able to use any of the facebook api features; any requests you make will fail.
I think the 'one app id for every domain' condition is more to target people who are trying to use multiple app ids for one domain. I think so long as you aren't transferring any data about the user to different domains/adverts etc, you should be ok. Essentially what you are doing is adding FB connect to your wikidot site, then a separate feature of wikidot is to keep you logged in on other partner sites?
I'm developing a small CMS in PHP and we're putting on social integration.
The content is changed by a single administrator who as right for publishing news, events and so on...
I'd to add this feature, when the admin publishes something it's already posted on facebook wall. I'm not very familiar with facebook php SDK, and i'm a little bit confused about it.
If (make it an example) 10 different sites are using my CMS, do I have to create 10 different facebook application? (let's assume the 10 websites are all in different domains and servers)
2nd, is there a way for authenticating with just PHP (something like sending username&password directly) so that the user does not need to be logged on facebook?
thanks
You might want to break up your question in to smaller understandable units. Its very difficult to understand what you are driving at.
My understanding of your problem could be minimal, but here goes...
1_ No you do not create 10 different facebook application. Create a single facebook application and make it a service entry point. So that all your cms sites could talk to this one site to interact with facebook. ( A REST service layer).
2_ Facebook api does not support username and password authentication. They only support oauth2.0. Although Oauth is not trivial, but since they have provided library for that, implementing authentication is pretty trivial.
Please read up on http://developers.facebook.com/docs/.
Its really easy and straight forward and well explained.
Your question is so vague and extensive that it cannot be answered well here.
If you experience any specific implementation problems, this is the right place.
However to answer atleast a part of your question:
The most powerful tool when working with facebook applications is the Graph API.
Its principle is very simple. You can do almonst any action on behalf of any user or application. You have to generate a token first that identifies the user and the proper permissions. Those tokens can be made "permanent" so you can do background tasks. Usually they are only active a very short time so you can perform actions while interacting with the user. The process of generating tokens involves the user so that he/she has to confirm the privileges you are asking for.
For websites that publish something automatically you would probably generate a permanent token one time that is active as long as you remove the app in your privacy settings.
Basically yuo can work with any application on any website. There is no limitation. However there are two ways of generating tokens. One involves on an additional request and one is done client side, which is bound to one domain oyu specifiedin your apps settings.
Addendum:
#ArtoAle
you are right about every app beeing assighend to exactly one domain. however once you obtained a valid token it doesnt matter from where or who you use it within the graph api.
let me expalin this a little bit:
it would make no sense since it is you doing the request. there is no such thing as "where the request is coming from". of course there is the "referer" header information, but it can be freely specified and is not used in any context of this.
the domain you enter in your apps settings only restricts where facebook redirects the user to.
why?
this ensures that some bad guy cannot set up a website on any domain and let the user authorize an app and get an access token with YOUR application.
so this setting ensures that the user and the access token are redirected back to YOUR site and not to another bad site.
but there is an alternative. if you use the control flow for desktop applications you don't get an access token right after the user has been redirected back. you get a temporary SESSION-TOKEN that you can EXCCHANGE for an access token. this exchange is done server side over the REST api and requires your application secret. So at this point it is ensured that it is YOU who gets the token.
This method can be done on any domain or in case of desktop applications on no domain at all.
This is a quote from the faceboo docs:
To convert sessions, send a POST
request to
https://graph.facebook.com/oauth/exchange_sessions
with a comma-separated list of
sessions you want to convert:
curl client_id=your_app_id \
-F client_secret=your_app_secret \
-F sessions=2.DbavCpzL6Yc_XGEI0Ip9GA__.3600.1271649600-12345,2.aBdC...
\
https://graph.facebook.com/oauth/exchange_sessions
The response from the request is a
JSON array of OAuth access tokens in
the same order as the sessions given:
[ {
"access_token": "...",
"expires": 1271649600, }, ... ]
However you don't need this method as its a bit more complex. For your use case i would suggest using a central point of authorization.
So you would specify your ONE domain as a redirect url. This domain is than SHARED between your websites. there you can obtain the fully valid access token and seamlessly redirect the user back to your specific project website and pass along the access token.
This way you can use the traditional easy authentication flow that is probably also more future proof.
The fact remains. Once the access token is generated you can perform any action from any domain, there is no difference as ther is literally no "domain" where the request is coming from (see above).
apart from that, if you want some nice javascript features to work - like the comments box or like button, you need to setup up open graph tags correctly.
if you have some implementation problems or as you said "domain errors" please describe them more clearly, include the steps you made and if possible an error message.