On some of our web apps, when a user connects via a Verizon 5510L Jetpack mobile connection the site address is replaced with an incorrect IP address, and of course throws a 504 error.
Has anyone else ever experienced this? or know why this is happening?
We have other apps that are very similar, on the same server that do not have this issue. Unfortunately this is a popular device with our customer so avoiding the hardware is not an acceptable fix.
As a workaround, the user can connect to the site via a different connection, keep the browser open and connect to their mobile device. This Also is not an acceptable fix as the applications are often used in remote areas.
Related
I have been trying to render localhost:3000 (React app) on my phone. I have tried the following,
Connecting my MacBook and the phone to the same wifi, getting the ipv4 address and adding port 3000 to it and accessing that IP address port combination in my phone.
I have tried turning off my firewall.
I also tried npm start --host 0.0.0.0
I am running localhost on my MacBook. My colleague who has a Windows machine is also facing similar issues.
Make sure that the wifi network's wireless settings do not prevent local clients from connecting to each other. There is a setting often called "Wireless Isolation" which is pretty common - enabling this results in clients only being able to connect to the outside internet, but not to anything else (such as other wifi clients) on the network. While this is useful from a security perspective when the network administrator doesn't know whether the devices that want to connect are trustworthy, it blocks network functionality. Go into the router's settings and turn this off if it's on.
We have a simple WP site that has been running for years. We can access it on mobile or any other computers that are not connected to our company's domain. I believe there is an error within our firewall. Any suggestions on where I should look? We use a Dell Sonicwall.
First check the logs, and see if it's being blocked. Then I would check app control, or the CFS policies. Probably, the easiest way would be to just put one test machine IP address in a CFS, IPS, or APP Control (or all) bypass group. Test you can get out to the site. Once you can access the site, start to re-enable all the security services one by one until you find out what's blocking it.
I have a local sandbox website on my computer running on nginx. I have chrome canary and that's what I"ve been using to test the various media sizes. Of course, this doesn't stack up against actual hands-on testing to get an idea of the feel of the website.
So, is there a way to be able to access a website running on my computer from the same network? Even if I have to use a specific app. I would like to use the same URL. dev.mywebsite.com and mywebsite.com run a on a server, sandbox.mywebsite.com is on my machine (this is the one I would like to access). I don't need to access to it remotely, just when I'm on my network is fine.
Note: I need to use the actual URL.
Thanks.
If sandbox.mywebsite.com maps to localhost on your computer, then by mapping sandbox.mywebsite.com in the hosts file of your phone to the local network IP address of your computer e.g. 192.168.1.9, you should be able to access it on the phone.
I have done this using android with hosts editor, connecting to apache running on an ubuntu laptop.
There are also many google results for this, so you may be able to find something there for your specific configuration.
I'm developing for mobile devices and to debug I connect devices on WIFI to my IP address. It works well for developing on hardware and debugging on my machine. The only thing I can't make to work is how do I set up Fiddler so it sees traffic coming from external clients?
If I open my site from browser on same machine - fiddler get's it. But when I connect to my PC by IP address from another machine - fiddler doesn't see it.
I have proper settings (I think)
You need to configure Fiddler as a reverse proxy. See Using Fiddler as a Reverse Proxy.
I got this to work by simply changing the IIS Application Pool whose traffic I wanted to inspect to run under my identity, since Fiddler seems to only capture traffic of the logged in user by default. Just make sure your user has all of the necessary permissions required by IIS; I'm an admin so this wasn't an issue for me. And of course, don't forget to change the IIS Application Pool identity back when you are done.
The other option of course is to instead log in as the user that the IIS Application Pool is running as (if it's not a service account like Network Service) and then run Fiddler while logged in as that other user.
OK, this used to work, but it appears to have stopped working on January 1st.
We have a .NET page that is displaying some data to our internal mobile users. This page is set up with Anonymous Authentication in IIS7. (Windows Server 2008 R2 is the OS of the web server.) When accessing via our intranet, the page displays fine. When attempting to access via our Blackberries, we get the following error message:
"Error: Page cannot be displayed. Please contact your service provider for more details. (1)"
Is this an IIS error, an AT&T issue, or a Blackberry issue? My Director is on my case about it, and I'm not experienced enough in IIS to know of anything else that would cause this functionality...
You should check with your network ops team. I'm guessing that the blackberries are accessing the server from the external intranet (that's just a guess though) ... so have them double check that the domain/ip is accessible externally. That could be why you can access it from in the network.
Or if your blackberries are configured to access the network via VPN, I would double check that connectivity.
Forgot to post the resolution to this.
It turned out to be a Blackberry issue. With the latest OS, RIM combined the internal and external browsers into one browser. Said browser attempts to determine if a given site is an intranet or internet site. Even though the BES (sp?) was set up correctly, our service was still spotty. Some people could enter our intranet homepage address and get the intranet; others got the web squatter site on the internet. Since the page we were trying to access was nested fairly deeply in the directory structure, the web squatters didn't have a page with that name in their site. That's why we were getting the error shown above.
Our resolution - we created a different BES alias to point to our intranet, and rolled that out to all applicable users. Utilizing this, the browser didn't have to determine if we wanted our intranet site or the page on the internet; it correctly displayed the intranet page.