I am trying to create an application on BlackBerry 9930 simulator that authenticate the user with Facebook, using the BlackBerry Facebook API. It connects to the login page fine, but after that the entire application crashes, either when asking to review the permission or when the login has succeeded.
I noticed that the authentication process went well since I get a message from Facebook that there is a login, so I am suspecting either the problem with the browserField and/or the simulator. (I tried 3 different BB 7 simulators, all the same though).
Anyone has a way to resolve this? Thank you so much.
It seems that no one has any solution for me :(. But, after messing around with it, I have found an explanation and a solution for it and I think I should share this with you. Sorry for the lateness in the response, though.
Here is the story.
As you probably already know, after supplying the credentials, Facebook returns the access token in the URI which is followed by the # symbol. Now, the BlackBerry Facebook API overrides the handleNavigation() method to ensure that, if the URL contains the access token, it will not be processed. This used to work in earlier versions (prior to BB 7) but somehow, it seems that URL redirection in BrowserField are no longer calling handleNavigation(), but rather handleResource() directly (I don't know why and, to my knowledge, there is no documentation for this change anywhere). The result? It always tries to process the URL that contains the #access_token in it.
Worst, the BB BrowserField thinks that # means a jump to a portion of the page (which doesn't exist). Other browsers (including the BlackBerry Browser) seems to understand that already and print only "Success" on the screen, while the BrowserField does not. And when that happened, the application just stopped working and crashed, sending me back to the home screen.
So what I did was I changed the source code of the BlackBerry Facebook API so that handleResource() now checks by itself whether the access_token is in the URL. Then, the application works fine.
Related
We have link functionality in our web application that when clicked, browses to a page on our server that performs the following:
Tries to open the custom url to our ios application
If this fails, it redirects the user to our ios app store to download the app.
This actually all works perfectly well.
However, it creates a weird corner case, where after a user has done this and finished, if they come back sometime later and open their safari on the same phone, if our web link is still the active tab, it will redirect them again to our application.
The cause of this is fairly obvious, but we are struggling to come up with a solution for it. Is there any known to rectify this behavior, either through a different mechanism then I described for opening the application or through somehow killing the page simultaneously?
I am trying to get Open Graph share actions to work on iOS. It's working some what, if I request the open graph url using the Open Graph Debugger first everything works as expected. However if I don't do this the preview in the share dialog is displayed for a seconds or so and then fades out. The post button is also disabled.
What I am seeing in the backend is that if I use the Open Graph Debugger or paste the object url into my own status I am getting requests from a Facebook server (69.171.234.117). However when I share directly from the application I am seeing a request from another Facebook server (173.252.74.115) this server doesn't seem to be able to read the Open Graph data correctly.
Has anyone seen anything like this before or know what's causing it?
EDIT: I've filed a bug with Facebook for this issue. Will updated here if it changes.
EDIT2: Facebook has confirmed this bug and is working on it. The suggested workaround for now is to trigger an initial scrape by using https://graph.facebook.com/?id={url}&scrape=true when the object is created.
EDIT3: Facebook closed the bug report and claimed the issue is solved in there latest SDK. I will verify this and report back.
EDIT4: This seems to be resolved now from my testing.
I encountered this issue before, it turns out that instances of custom open graph objects that are hosted on your server are instantiated only when they are related to for the first time.
Only when the first edge in the FB graph is assigned to your object is it that it obtains an Identifier and it exists in FB's records.
This first edge can only be created using the FB app or the open graph application.
After that's done you will be able to get a unique identifier for your object
GET https://graph.facebook.com/?ids=YOUR_OBJECT_URL
Then you could perform the share using the returned ID
Also see this SO post which supports my claim.
I created a router that connects to facebook to get some info before a user may access the internet.
First they connect, get the Captive Portal Page and then continue to a facebook login. Since the upgrade to iOS7 it fails to load the facebook login page. On my mac with the Captive Portal Assistant it has no problems and even on the phone itself while using the iOS version of safari there are no problems.
What is going wrong here? Is facebook filtering request from the iOS7 Captive Portal Assistant or is Apple doing some sneaky stuff here?
It seems the problem is widespread and only related to facebook.
Update: I worked with the beta's and they worked fine a few weeks ago. Now with the same beta version it doesn't anymore. So another point for the facebook explaination.
Regards, Cas
This problem was fixed by Apple since IOS 8. But as all iPhone 4 users can't upgrade to IOS 8 this problem is still one.
The IOS 7 devices check for the following domains:
www.appleiphonecell.com
captive.apple.com
captive.apple.com
www.apple.com
www.itools.info
www.ibook.info
www.airport.us
www.thinkdifferent.us
Whitelisting this domains stops the login mask to be appearing as the IOS device thinks, that the internet is working as expected. This way you have control on the things which happens, as the IOS device does not interrupts anything, if you use a normal browser for login.
If you don't whitelist the domains, the following thing happens. I debugged it on routers with several IOS devices and they all did mostly the same:
If you connect to a wifi, the IOS device tries to connect to one of the domains, which are listed above. If it can contact one of the domains, it tries another one. If it can't, it starts the redirect, which is controlled by the router. Sometimes it query one or more domains, before it thinks, that the internet is working.
After the check, the login screen redirects to your router and then to the login screen of your captive portal. This behavior stayed the same as it was on IOS 6 or before.
Now you start an oauth login to a 3rd party provider like Facebook, Google or Twitter. And now the difference appears. You can check it on a router, if you run it in debug mode. As the IOS device goes to an other domain for oauth login (like www.facebook.com) the iPhone thinks, that something changed and starts to query one of the apple domains, which are listed above. The user sees only a white screen and in the background the IOS device tries to contact one of the domains repeatedly. For the user this seems to be an error, as the screen stays white or takes very long to show the login on the 3rd party provider. Sometimes it stops loading and nothing happens forever.
To avoid this behavior, you must whitelist the above listed domains. This is a not a common behavior for IOS users, but this way, your browser have the control of the login session and the IOS device don't interrupt it as it does with the login screen.
Some shallow parts of information is reported on the following sites:
https://supportforums.cisco.com/docs/DOC-36523
http://www.cadincweb.com/why-your-apple-ios-7-device-wont-connect-to-the-wifi-network
https://discussions.apple.com/thread/5355766
I couldn't find a detailed description of the problem and found the one above myself by debugging all parts with some routers and IOS devices like iPhones and iPads.
I've just tested various router settings and noticed that iOS 7 is NOT trying to contact above mentioned sites/URLs when router's DOMAIN field is blank.
My guess is that blank domain points to a consumer-type network set up and Apple is not expecting a Captive Portal at such network. If you have access to administer your router see if you can clear out the DOMAIN field (and restart/retest).
I found my solution to my problem. (a while ago, but I found this post again)
First I found out, iOS makes 3 calls, first to check, second to get the page that needs to be displayed, third to check again after the pageload. Then I discovered, for every POST or GET action made by the page, regarding of the source page was refreshed, iOS checks for an active internet connection. Since the facebook api makes a lot of calls, the browser starts stalling(possible in combination with QoS on my router) and freezes the page.
My Solution:
Since I am in control of the DNS records of the Router I use, I redirected all domains towards my own server.
First I saved the check request, this to later identify the user when he comes back for the 3th request.
When the second request comes I just display an info window that every thing is right, and the user has to click the "Done" button.
The page is loaded, so iOS checks again, but i recognize the user so I display the OK-code Apple also displays. The "Done" button us show, and the user has "internet", according to iOS..
On the page that I display, I instruct the user to open the webbrowser. When he does, he opens a page and my portal with the right page is shown(I can detect this based on the Browser Agent). Then my facebook api start doing its job, and of we go :-)
Let me know if someone needs some more info on how to detect or maybe even a code sample if necessary.
Extra Information
To capture a user on your own server, redirect every request to your processing page using for example .htaccess. The request is made to a domain with a subfile e.g:
http://captive.apple.com/getrT09Nx7G/YNrnUOulnDj/3cfrq3M40iR.html
To keep multiple users apart, use the unique url the device tries to contact when checking for internet, in this case: /getYT09Nx7G/YN1nUOulnDj/3cfMq3M40iR.html
I've got (actually my employer has) a mobile website that enables Safari integration (for iPhones and iPads) - meaning that customers can bookmark it to their home screen and then it would behave as a standalone web app (no address bar, custom icon, start-up image etc).
It works all right except that one week ago (coincidentally soon after apple has released iOS 6.1.2) some of our customers (6 of them initially) complained that they no longer get the normal content but a '404 page' of a public wifi provider (The Cloud owned by Sky here in the UK). After a bit of investigation we've figured that at some point those customers connected to the Cloud wifi without actually logging in (it's one of those providers that would redirect you to a login page to enter your credentials, after which you can carry on browsing). The thing is that even after switching back to their private wifi or mobile data connection the application would display the Cloud's page.
This only happens (as far as I can tell) when the application is launched via the bookmark (I couldn't see this behavior when using it from safari).
What happens is that the customers would connect to the cloud wifi (without logging in), they would open the application at which point the router will issue a redirect response to their login page; the application would cache the login page and it will always display it whenever using the bookmark again. (I've performed a capture when this happens and there are no requests being made at start-up whatsoever).
Even weirder, in this situation, if removing the existing bookmark and adding a new one will show you the same cached page (with the whole operation being performed away from the Cloud). We've fixed this by adding a unique identifier to the URL each time we hit the bookmark screen (this indicates that the web apps' sandboxes are linked to the url, which is to be expected).
What we're trying to achieve is to have the application properly recovering after the customer has moved away from the Cloud. But there doesn't seem to be a straight forward way to do this.
Furthermore there's a level of inconsistency in all of this - most of the times when the flow is performed I will see a 404 page (a custom 404 page https://service.thecloud.net/service-platform), but sometimes I would be properly redirected to the login page, in which case the application would not break.
My assumption is that there is a weird race condition in the standalone web app application model causing the browser not to properly handle redirects (and actually caching 404 pages). I've raised a support incident with Apple (which eventually turned into a bug report) but it might take a while and I'm trying my best to figure out a workaround.
Any ideas, maybe someone has seen this before?
The issue is aggravated by the fact that I need to have a 5 minutes walk ever time I'm testing any fixes; I've tried creating simple test forms, but I wasn't able to reproduce the issue, where as with the full app I can do it pretty much every time.
Here's a summary of the steps to reproduce:
Via private wifi (or mobile data connection) add a bookmark to a website (I've managed to reproduce it with quite a couple of apps that support safari integration as described above)
Open the application to review the normal content
Connect to a Cloud hotspot and open the application from the bookmark (open-close it for a couple of times if you don't get the 404 right away)
Connect to the private wifi (or mobile data connection) and open the application via the bookmark -> you'll see the same 404 page again
In the end the fix was to add a unique query string parameter with the initial page request (pretty easy with the setup we already had, via the launcher page). I've filed a bug report with Apple which they've acknowledged by linking it to a previous item. Here's a post on the topic:
http://blog.onos.ro/ios-6.1.2-caching-issue
I would like to have my native iOS app send a request with a parameter to a Facebook user on iOS. If they accept, it will launch my native iOS app and pass it the parameter. Is this possible?
I am having marginal success using [facebook dialog:#"apprequests" andParams:dict andDelegate:self]. I am getting the bookmark counter to increment on Facebook iOS app, but I do not see the individual requests. If I tap the bookmark it launches my app but I do not see how I can get the "data" parameter I passed with the request, or even the request_id.
On desktop I see the individual messages under "Requests" section of "Apps and Games". If I accept a request, I can see it pass the request_id to my (simple echo) canvas URL. I read this can be used to fetch the associated data. But, this does not help me on iOS. My app only runs on iOS, so this canvas app will eventually just be a "this app only works on iOS," but it seemed to be necessary to get the requests to flow.
Neither of these are showing me Notifications, so maybe I am doing something basic wrong. Or, is there some other way to pass a message to a Facebook user, with a URL they could click (to launch and feed my app its parameter).
One other odd thing, I do not see how to get rid of the Requests. If I "X" them on the desktop client, it asks me if I want to stop receiving all requests from my app, and if I say no, it only hides them temporarily.
Leif, Hi - I'm the engineer at Facebook who wrote the tutorial you've referenced.
I've taken a look at the issue you've mentioned - this is in fact not a bug in the documentation and is by design.
The incoming url from a request on iOS looks something like this:
fb480369938658210://authorize?expires_in=3600&access_token=BAAG05NeN86IBAC31YWMWRHVrNCAYMy0Rv1OtqZCwdH8QDBUAt5KgZCsIbU0EOZAvMms2tZCANV9sZBWSkEzStDtt4i7YnYZA4bPgGx2XaI5s22iBMxIZAneZAv7ADi3Wi20ZD&target_url=http%3A%2F%2Fm.facebook.com%2Fapps%2Ffriendsmashsample%3Ffb_source%3Dnotification%26request_ids%3D364209433669109%252C379616028785376%252C494409170593789%252C489782271042929%252C328564930575784%26ref%3Dnotif%26app_request_type%3Duser_to_user
This is bundling together several requests, with multiple request ids into a single url.
To get the extra data coupled with this request, it is not required to have the user_id. Hitting graph.facebook.com/*request_id* is enough.
You can actually see this outlined in the documentation here: https://developers.facebook.com/docs/requests/#deleting under the 'Request ID Format' heading.
The code contained in the Friendsmash sample and on the tutorial works correctly - I verified it just now. So it should serve as a good guide to the OP's question.
Thanks!
I have been struggling with this too.
First, the FB iOS SDK requests tutorial is a good start.
However, there are also a few bugs that makes things not work as expected:
It seems that currently, a mobile web url has to be set up for the FB app in order for requestIds to be forwarded from the native FB app to your native app. See this bug report.
The tutorial mentioned above uses an erroneous graph path for the request object. I uses "request-id" where it should be "request-id"_"user-id". I have filed a documentation bug report on that issue.