Facebook developers: Please star this issue

46 views
Skip to first unread message

Jeff Schnitzer

unread,
Feb 25, 2010, 2:15:53 PM2/25/10
to Google App Engine
If you are currently developing a Facebook Connect app or plan to
develop a Facebook Connect app, please star this issue:

http://code.google.com/p/googleappengine/issues/detail?id=2878

If you haven't noticed, you soon will: You cannot test your FB
Connect app using XX.latest.example.appspot.com. FB Connect requires
that you specify a single domain for your application (example.com)
and all other domains (example.appspot.com) fail. This makes it
impossible to simply deploy a new version of your code and run it
against your live data.

The requested feature: Please allow us to run XX.latest versions on
our custom domains.
Example: XX.latest.example.com

Like me, you're probably testing in dev mode with an alternate FB app
key, crossing your fingers, and hoping it works when real users touch
your new code. Or maybe you dare to test in vivo with your alternate
app key, but things don't work quite the same because the live data
contains users who haven't authorized your alternate app key. Like
me, you've probably exposed real-world users to bugs because you can
only test against live data by deploying it to the default domain.

Please star the issue.

Thanks,
Jeff

Waleed Abdulla

unread,
Feb 25, 2010, 4:12:46 PM2/25/10
to google-a...@googlegroups.com
It's a good issue to raise, but shouldn't that be raised to Facebook instead? They need to allow running FB Connect apps on more than one domain. 

Waleed





--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.


vivpuri

unread,
Feb 25, 2010, 4:28:22 PM2/25/10
to Google App Engine
First, it is a facebook issue
Second, you can create a tmp facebook app for testing that points to
the versioned appengine app. Still debugging for existing users is a
pain. It would be better that facebook let you point app to a sandbox
server/url

Vivek

On Feb 25, 4:12 pm, Waleed Abdulla <wal...@ninua.com> wrote:
> It's a good issue to raise, but shouldn't that be raised to Facebook
> instead? They need to allow running FB Connect apps on more than one
> domain.
>
> Waleed
>

> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>

Scott Hernandez

unread,
Feb 25, 2010, 5:45:31 PM2/25/10
to google-a...@googlegroups.com
This isn't a facebook issue at all. Facebook just exhibits this
behavior, like many others.

Really, you need to be able to run against the different versions of
you app using your custom domain. Think cookies; you cannot access
cookies on other domains. You cannot test "real world" behavior if you
have to test on a different domain, than the ones you actual deploy
on.

> To unsubscribe from this group, send email to google-appengi...@googlegroups.com.

Waleed Abdulla

unread,
Feb 25, 2010, 5:56:32 PM2/25/10
to google-a...@googlegroups.com
I guess it depends on your definition of "issue". For me it's a problem because, in addition to the testing use case mentioned earlier, I have two other cases where I need to run a FB app on separate domains but I can't. 

1. I have a short domain that I use in some cases for sharing content (to keep the url shorter), and although it's really only a different domain for the main site, Facebook Connect will not work on that. I have to use iframe tricks to get around the restrictions. 

2. Even in a regular Facebook app that runs inside facebook, I sometimes want to point different functionality to different domains for load balancing purposes (e.g. have canvas pages render from server1.example.com and tab pages from server2.example.com). Again, I can't do that. 


Apologies for deviating a little from the main topic of the thread, though. It would be nice to be able to use multiple domains with a Facebook app, but it's clearly something to be discussed with facebook, not on this list. 

Waleed

Jeff Schnitzer

unread,
Feb 25, 2010, 5:57:05 PM2/25/10
to google-a...@googlegroups.com
On Thu, Feb 25, 2010 at 1:28 PM, vivpuri <v...@vivekpuri.com> wrote:
> First, it is a facebook issue

No, it is NOT a Facebook issue. It's an issue with any system that
relies on cookies or third-party code that is sensitive to domain. It
just happens to be a particularly nasty problem with Facebook.

I want to deploy my beta code to appengine and test it *with no other
changes whatsoever*. If you take testing seriously, you want this as
well.

Forcing beta testers to use XX.latest.example.appspot.com presents an
entirely new set of cookies to the system. It's not a question of "go
to this new URL and see what happens", it's "go to this new URL, log
in again, get back to the same UI state you were in, and hope that the
original problem wasn't caused by cookies that are now masked".

> Second, you can create a tmp facebook app for testing that points to
> the versioned appengine app. Still debugging for existing users is a
> pain. It would be better that facebook let you point app to a sandbox
> server/url

This adds *yet another* variable to the testing process, and quite a
dangerous one at that. For different applications:

* The app settings in facebook might be different depending on what
engineer was testing that day

* The social graph of "friends who have installed your app" are
wildly different

* Data you have persisted in Facebook for the user (using their data
apis) is totally different.

* If you record information based on these last two points, you can
easily trash your live data.

Of course Facebook could *partially* solve this problem by allowing a
second domain for testing. But this still doesn't solve the cookie
issues. It would be *far* better for developers if we could visit two
urls, sharing cookies but running different code:

http://www.example.com
http://XX.latest.example.com

Jeff

Reply all
Reply to author
Forward
0 new messages