I'm trying to set up a manual oauth flow to sign my users in via facebook, pretty standard fare.
I have the redirect working properly and it sends the code to my callback function. I then have to exchange my code for an access_token with facebook. That is taking 60+ seconds if it doesn't just completely time out. I've done this exact same functionality multiple times before and have had no issues. Other sites will respond instantly while facebook for some reason takes 60+ seconds. Keep in mind that this same code ran in my production server's rails console works instantly. If I do an equivalent request via curl it also works instantly. This issue is ONLY happening in the Rails Console on my local machine. I tested with RestClient and HTTParty and got the same results.
url = "https://graph.facebook.com/v2.8/oauth/access_token?client_id=#{CLIENT_ID}&redirect_uri=http://127.0.0.1:3000/facebook_oauth_redirect&client_secret=#{CLIENT_SECRET}&code={#CODE}"
response = RestClient.get(url, :content_type => 'application/json', :accept => :json)
I can not figure out what is going wrong. I suspected maybe something with SSL but I can get responses from other https sites without issue. I got it down to the TCPSocket itself taking 60+ seconds to be opened.
s = TCPSocket.new 'graph.facebook.com', 443
That takes about 75 seconds to open while other sites are in a fraction of that time. My coworker confirmed he can open the TCPSocket instantly. I'm all out of ideas at the moment so any advice would be welcome.
EDIT: Seems that the issue is probably my new wireless router I got a few weeks ago. I hooked my Mac up to my iPhone hotspot and it worked instantly.
The solution ended up being my wireless router or modem, not entirely sure what. Money is on the router since I upgraded a few weeks ago.
Power cycling wasn't helping so I spoofed the MAC address and that seemed to solve the issue after a power cycle.
Not really sure what the issue was considering that everything in browser/curl was working fine, the issue was just rails console (which the spoofing fixed).
Related
I am working on mobile pentests currently. At first, using my home network I was able to intercept traffic on burpsuite for both iOS and Android versions of “Test App”. Then the next day, I still am able to intercept traffic but the behaviour of this “Test App” for both iOS and Android seem like it has certificate pinning as I was just stuck on the pre-auth page and getting errors when trying to log in. Without proxy though I am still able to login OK and proceed with the app normally so I don’t think my home network got blacklisted? (For context, the binaries does not have any certificate pinning).
But when I tried to change my network to my mobile hotspot, I could intercept the traffic and app behaves normally again.
Anyone encountered the same previously? Any ideas on what could be causing this? Thanks
This does seem odd. I would wager one of three things is happening here:
You accidentally left "Intercept" on in Burp Suite Proxy. This holds the response in Burp Suite until you click Forward, which would cause behavior very similar to what you are describing here. I have done this more times than I am willing to admit.
There was a temporary outage in the application's API. Not unheard of, especially if this is an unreleased app.
There is some sort of issue on your home network, but this is unlikely. Maybe two devices have the same static IP address?
It's hard to say exactly what the issue might be based on the information you provided, but hopefully this was helpful, or at least gives you a place to start!
recently I’ve been running into an issue getting file downloading working on iOS. It seems like specially for Chrome/Firefox on iOS, the device requests the download route twice, once before the user clicks the ‘download’ prompt, and once again after the user presses it. This is not a problem on Safari for iOS, and it breaks the authentication for my download routes.
I did make a demo: https://github.com/subnub/ios-chrome-download-example
You’ll notice in the demo that if you use Chrome or Firefox on iOS it requests the download route twice, not only that it will serve up all the bytes of the first request, and just discard all of them. But, if you use Safari, it will only make the download request once like it should.
Any advice would be greatly appreciated, I’ve been stuck on this for some time now.
In the apple WWDC 2015-504, the SFSafariViewController has been announced.
Ricky Mondello claimed that the new secure, stable, and fast embedded Safari browser is capable of creating authentication flows, with two easy steps, passing though AppDelegate.
I wanted to give it a try, so i searched a bit on the implementation for OAuth2 using SFSafariViewController... I found almost nothing. There are plenty of articles explaining why the SF(...) is better than a UIWebView and so on, but i couldn't find a working implementation, not even in GitHub.
I tried to open a simple url such as "http://www.google.com" and everything works just fine.
I wanted to go one step further: i've tried implemented login with OAuth in order to receive the auth token (first step of flow).
So sent my SF(...) to "https://website.com/auth?ID=...&access=..." and set as redirect URI testApp:// (The name of my app).
I was expecting to see the request in - application:openURL:sourceApplication:annotation:
but nothing at all happened.
I've also added "testApp" in 'LSApplicationQueriesSchemes' but i have had no luck.
It's been one day struggling on this problem, and i would really like to know what am i doing wrong.
Thanks.
After another day, i can assume that the iOS 9.0.2 Jailbreak was causing the url scheme issue.
Our Webapp site has strange problem where we get occasionally huge number of page reloads from Apple iPad Safari.
What happens is that Safari opens keep alive HTTP 1.1 connection to our server and issue streams of GETs to it. The requests can arrive only tens of milliseconds from each other and it seems Safari is reloading the page as soon as it gets response to previous request. After sending 4-5 requests, Safari closes socket, opens new and same thing repeats for several minutes until it suddenly stops.
Things checked
Happens only with main page root url /
Page has no window.location.reload call on load that could cause this
Confirmed with tcpdump and wireshark that problem is real and happens between iPad device and our server. (i.e. not problem with haproxy, our servers or buggy logging)
Problem seems to be mainly with iOS 4.3.3
I can not ask the users and we have not repeated this locally with testing devices
All problem requests come from single IP that seems like VPN gateway of a school but from different random users (based on cookies same users may use webapp days successfully until problem repeats)
Has anyone idea what might be happening here?
Broken proxy somehwere?
iOS HomeScreen webapp bookmark gone haywire?
DoS attempt, though lame one
People turn zombies while using our webapp and instead of Brainsss they crave Reloadss?
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.