OK, this is weird.
We have a test website (just a payment form) here: http://blog.inglesen100dias.com/
The problem is that everyone I've talked to but me can see the form (our hosting provider, other coworkers in different states/countries, etc). Me, I see a 403 forbidden error, "You don't have permission to access / on this server."
We made a change earlier today in that subdomain, changing the A record to point it to a different server. But for some reason everyone but me can see the new page where it's pointing at.
I've deleted the cache, flushed the DNS (I'm on Windows 8), entered the website with my cellphone (same error)... so I don't know what else to do. My impresion is that when I access that URL, it's still trying to open a location in the old server (where the domain originally pointed), instead of in the new server. Why this only happens to me?
Any advice would be very welcome!
UPDATE
I've turned-off the Wifi in my cellphone (it's connected to the same network as my computer) and now it shows the right page! If I turn the wifi back on, then it shows the 403 error again...
Can it be a problem in the router?
I restarted the router and now it's showing the right page!
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!
I am trying to implement a splash page/ wifi landing page on my existing public wifi network, using the DNS method mentioned in Wiki, in which I host a custom DNS server, that will redirect ALL dns lookup to a local address where a web server is hosted, for all user before they click agree.
After the user clicked agree, my custom DNS server starts returning correct ip for the look up, thus, user will be able to get online.
note: We totally understand that this is in no way secure our network, and even putting our network at risk. But the goal here is to just to pop the landing page up in front of our users.
This approach actually works on Windows Phone (Windows 8 I tested) as splash page, and even on a computer when I try to open a random website, it redirects me to my page, and after I hit agree, I can get to the internet.
When I try it on iPhone/ Android, once I connect to the hotspot, the splash page/ wifi landing page appear as expected (because the device is trying to verify internet access by going to the set of pages) However, after I click agree, and allow internet access, both iPhone and Android splash screen will not go away. I have to force iphone to "use this wifi without network" to exit.
I wonder if there is a special (javascript?) method I can call in the page, or some package I need to send to the device? I noticed on iOS, if I click a link to the App Store, the splash page go away without disconnecting from the network, So, I guess I am missing something here.
For example, clicking the link to the iOS StackOverflow App on iOS device can be a workaround.
Had been googling around for a week now, nothing seems to came up.
by the way, I am building my custom dns server on node js, with the module dnsd.
=-=-=
=-=-=-=-= edit =-=-=-=-=-=
I also uploaded a demo of my code on GitHub:
https://github.com/kylelam/dnsd_wifi
To test it, run it in your local network (sudo node demo.js). Then, change your phone's dns to your machine's IP. Disconnect your phone from wifi and connect to it again. (on iOS, you might need to go into detail, and enable auto-login, and auto-join, or if you can't, just reboot.)
*note1: the server will need to run on port 53, and 80, so it need sudo.
*note2: please don't laugh at my code, I'm very new to this. But please do point out.
*note3: you will need to npm install these packages: os, express, dns, dnsd
ttl set to 0 might be the cause of the issue, try a different value like 5.
I have tested my website thoroughly offline (just using localhost). And I have never had a problem with appcache - such that I could load my website, disconnect my phone from the wi-fi, reload the website and I could still view it.
Now I have put my website online (ie. http://subdomain.example.com) - the code is exactly the same - and I try the same thing.
It will just not work. Chrome on my phone says wi-fi and mobile are unavailable and the page can't be loaded.
I just don't understand. Is there anything that anyone can think of that is different about working locally to working on a remote server?
If anyone else has this problem in the future, check your paths in .appcache
In turned out that the change between local and online (ie. 10.0.0.10/myapp/Symfony/mobile vs subdomain.example.com) meant that the / I had in the first line of my manifest was pointing to different locations on both local and online.
Yesterday (February 4, 2015 at 23:20:35 GMT-2) I received an email from an user frustrated that couldn't watch videos in my site (the focus point). All videos couldn't be watched and displayed an error, as seen in the image below:
Videos are from Vimeo, and my site's on Heroku. As far as I can tell, the entire site was working, no error logs near that time (I even used it 30 minutes later and could watch the same videos the previous user was supposed to watch) Vimeo shows no error by that time too, the user just said every embed videos were displaying above message.
The weirdest thing is that Heroku is being mentioned inside Vimeo's box with the error.
I think that's very situational, but I'm not sure if it will happen again, can this be fixed?
Did you recently create a public domain name for your app and setup a DNS CNAME alias?
The issue you're describing sounds like you provisioned a new domain name for your app in Heroku, setup a DNS CNAME, and then your user clicked on the site before the DNS CNAME record had propagated out into the world properly.
This is an edge case that should only happen during the DNS CNAME TTL update (usually an hour).
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