I am using History.js for history management in my web app. Everything is working fine for all modern browsers when the app is being used directly on my website. All of these browsers except from IE9 also work fine when the app is being loaded from within the Facebook framework (as a Facebook app). With IE9 it seems that the pushstate method is unable to get the state added to the history.
I guess it has something to do with Facebook sandboxing the app. Since IE9 does not natively support HTML5 history methods, it makes use of URL hashtags. Is there any particular reason why this does not work in a Facebook app. And is there any solution to the problem?
IE9 does not support PushState. Check this out http://www.quora.com/Does-Internet-Explorer-9-support-pushState
Related
I have been building an app using the php sdk for Facebook. The app works perfectly in chrome and Firefox, but when I try in Opera, basically when trying to log in to Facebook the page just reloads.
On occassions I can log in to Facebook, but when click allow to permissions the page doesn't do anything. I have the browser.js enabled but wanted to find out if this was a common problem and if there were any work arounds.
The Facebook connect JS library contains some pseudo-browser-detection that can cause problems. Opera actually tries to work around some of said problems in browser.js - have you tested with browser.js disabled too? The workaround itself might cause problems..
I am testing our web application on OPera Mobile. We have a signIn through facebook link. It takes me to the login page, but after I enter my ID and password nothing happens. If I click on the login button mutliple times, it gives me too many failed attempts error. But after this my facebook account seems to be logged in.
If I login to facebook and come back to our application and click on login, nothing happens, I see a blank page. After I did Javascript debug, I could see that the FB.login() callback is not running at all.
Can any of you tell me what could be the reason?
Thanks,
Yamini
Facebook Connect contains some browser sniffing (or "pseudo-browser-sniffing", detecting some features and making assumptions about what browser is used and what other features are available). They have functionality that uses HTML5's window.postMessage() which ought to work just fine in latest Opera on both desktop and mobile, but due to the unfortunate sniffing approach they send Opera down another branch in their script. To be fair, this is for historical reasons, the postMessage() support was in flux for a while while HTML5 was shaping up and getting agreement on all details, so there are probably still some implementations (earlier Opera and IE versions?) that are still in use and would not work with Facebook Connect's JS.
Ideally, Facebook would fix this. I will follow up with Opera (to double-check that what I recommend Facebook should do will work on Opera Mobile) and Facebook (to try to get their browser detection adjusted).
I'm working on integrating Facebook with my iPhone/iOS application and I want to know if I'm understanding the nature of the login procedure correctly.
With the old Facebook SDK ('Facebook iPhone SDK'), when we needed to request authentication permission from a user a UIWebView would be displayed with a login prompt. With the new SDK ('Facebook SDK for iOS'), the SDK uses Apple's fast-app-switching feature to temporarily place the app in background mode and then load the iOS Facebook app or Safari to authenticate. Is this basically the gist of it?
I've experimented with authenticating my app via the new SDK's technique and due to the nature of my app, it just can't support backgrounding. Does this mean I have to use the old SDK to launch a UIWebView-based authentication? I think this implementation is a lot cleaner anyway. Will I run into any major disadvantages from doing this?
Check out this question and my answer: Iphone facebook connect example calls safari. I don't want to use safari
You can make it use the UIWebView always. Facebook is trying to make it so the user only has to log in once per device (through either the Facebook app or in Safari) but I didn't like this flow (especially on the iPad). Though I'd rather not muck around with the Facebook code, I did find commenting out a few lines to be a quick way of getting the old behavior back.
I don't believe this is the case.
The Facebook SDK that I'm aware of, available at https://github.com/facebook/facebook-ios-sdk doesn't do anything like you describe. Is this the SDK you're using? I believe the last major update to this SDK from the "old" facebook SDK was to add support for OAuth-style authentication. With this change they broke code compatibility so apps were forced to make changes to incorporate the latest SDK.
When you call 'authorize' in this SDK you pass the app id, the desired permissions, and a callback delegate for notifications of errors or success (did login, did not login, did logout). You can also set any access token that you might have persisted from a previous session. Facebook validates this access token, and if it doesn't exist or is invalid it presents a modal login dialog. I believe the content of this dialog is a web page. The SDK authenticates the user using OAuth and makes the auth-token available for persisting between sessions.
At no time is the app exited to run the Facebook app or Safari. I'm curious - what led you to believe this was the case? (Or, perhaps there is some other SDK out there I'm unaware of?)
Take a look on this page: https://github.com/facebook/facebook-ios-sdk
And look at Single Sign-On. That describes the above scenario with fast switching.
I'm building an iPhone webapp (using JQTouch at the moment). It's a fullscreen app, you know, the ones installed on the home screen without the Safari chrome. If you tap a normal link (without AJAX that is) the link opens in Safari, taking you out of the webapp.
Is there a way to build non-AJAX webapps for iPhone?
The problem is AJAX isn't always a feasible solution. I would like to implement OpenID for this particular webapp for example but it means you have to redirect to an OpenID provider which links back to your URL but... without AJAX off course...
PS: I know you can build "real" apps with PhoneGap (and others) and I even built native apps before but, to be honest, I'm tired of paying €70/year for building free apps (it's for a hobby project, nothing professionally).
I think you can open OpenID links in iframe. OAuth, Facebook Connect, etc, all can work in that way.
I have been using single sign on authentication for my facebook canvas iframe app.
It works fine on IE, Firefox, Chrome(all latest). But doesn't work on Safari 5.
I know safari doesn't allow cross-domain cookies, and that's the reason it's not working. Facebook sets cookie for my app's domain that I can use as single sign on mechanism.
If I go to Safari's Preferences and set to allow cookies always and not only for sites I have visited, the entire app works fine. But, I don't expect every single safari user of my app to be doing that.
Has any one got this working? I tried using couple of other apps, and they seem to work but not sure if they use single sign on approach to authentication, which is actually recommended by facebook documentation. Do you think I should be using another approach that can fix it for me?
Info: I'm using ASP .NET MVC 2
Thanks
This worked pretty well for me.. http://forum.developers.facebook.net/viewtopic.php?pid=257432#p257432