Status quo
I'm running apache2 on raspiban. I have created a web page. I would like to embed camera streams from motioneyeos as fast network camera. The cameras are located in my local network and are not accessible via the internet. Short, I would like a surveillance hub accessibile via the internet.
It should look like this:
<img src="http://192.168.0.53:8081/" alt="camera1">
Problem
The streams can't reached from outside of my home network.
How can I route the stream connection via the web server to access the camera?
Approaches
I tried routing with ReWrite in .htaccess like this
Redirect 301 /camera1/ http://192.168.0.53:8081
of course same Problem.
I don't want the camera streams public because I can't protect them with a password. Unlike the website.
Would be grateful for tips or links to similar problems/solutions.
Related
I'm trying to create a wifi hotspot in windows 10 that redirects the connected devices to a specific HTML page, hosted on the pc. I can create the hotspot. Is there a way to force a HTML page load, like some routers do?
The plan is:
1- The user will connect to the pc wifi hotspot.
2- The user device will load a HTML page hosted on the pc.
3- The user will download files through the links on the HTML page.
The simple way to do that is to install any DNS server. This article can help to choise one. After that you can redirect all DNS requests to your PC. However it does not ptotect from opening web page by its IP.
The other way is to have Proxy on your PC that will redirect all traffic.
I got an Amazon ec2 server and when I go to the URL (Public DNS (IPv4)) in my browser I get "ERR_CONNECTION_TIMED_OUT"
I did the tutorial "Installing a LAMP Web Server on Amazon Linux" http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-LAMP.html
But got stuck on "If you are unable to see the Apache test page, check that the security group you are using contains a rule to allow HTTP (port 80) traffic."
I checked the security groups and they both set to "All traffic
All
All
sg-7496280c (default)"
And I still can't see the test page. I've also tried using the public IP address and I get the same thing.
There were no errors when installing packages.
I am able to connect using winSCP and upload html files but it doesn't serve them.
I don't know if I'm doing the right tutorial, or if I need to do other things first, or which tutorials apply to which types of servers or if ec2 and aws are the same thing or not etc.
I tried contacting support but it said I don't get technical support for basic accounts. I tried posting this on Amazon forums but it said something like "you can't post new threads right now, try again later"
I'm only doing any of this because you can't run node.js on hostgator.
ERR_CONNECTION_TIMED_OUT only happen either your apache not running or your server or your server is redirecting too much
Just I am unsure where you uploaded your HTML file and with what permission.
Do the basic thing reinstall only apache first.
check in your inbound and outbound port in aws security group in aws dashboard
if 80 port is open with anywhere option
check for
security rule
See if apache default page come. then upload your file.
can you tell in what directory you uploaded all your HTML
"ERR_CONNECTION_TIMED_OUT" can also be happen if you have not properly configure security group while creating the EC2 instance as it allows specific traffic to reach your instance.
If you want to set up a web server and allow Internet traffic to reach your instance, add rules that allow unrestricted access to the HTTP and HTTPS ports.
and copy Public IPV4 and use to visit the webpage rather than copying the url.
I've got a requirement to detect if a webpage is being served on the internet or intranet, i.e. assuming a url of https://accessibleanyway.com, is the phone connected to the work wifi or to something else like their home wifi or the phone network?
What different ways are there to do this?
(1) Use WebRTC to get the local ip address. Not widely supported
(2) Try to access a local web page using jsonp/cors/iframe
The problem with 2 is that the webpage is https and the local resource is likely to be http which you can't do in IE afaik. If I make the local resource https then it's via a self cert which means installing CAs on the phones (can you buy certificates for the intranet anymore?)
Any suggestions?
The problem with (2) was that the same page was trying to use http and https, and even with an iframe you get issues.
What you could do instead is start on a http loading page, use an iframe to access a local resource which you can only access if you are on the intranet, jsonp will work fine for this. Once that's worked or failed, redirect to your start page with some token in the querystring to indicate that you are on the intranet or not
NB jumping from http to https would probably have some security issues if you are on the same website (authentication cookies being initially visible), but I would have thought it would be fine if you are going to a different one
Obviously there'll be some security needed around the token as otherwise the user could just generate their own but that's a different matter which depends on individual setups. It would obviously have to be generated by a server call, otherwise someone could just read the client code.
NB I think the IP address approach is never going to work as you have no way of knowing what a companies intranet setup looks like until you go there, so it's not a generic answer
I apologize for my lack of knowledge on how the intricacies of the web work ahead of time.
I run a fairly large deal site (lets call it dealsite.com) and we send a lot of traffic to Amazon.com. Is there anyway for me to hide from Amazon that the users are are coming from dealsite.com? I do not want Amazon to know that we (dealsite.com) are the ones sending the traffic.
Maybe strip certain cookies?
Send outbound traffic through a proxy?
I am not doing anything illegal and these are real users not bots.
By using the noreferrer tag on your links, you can prevent Amazon from learning their traffic is coming from your site, and you don't need to set up a proxy, vpn, or cookie redirects.
HTTP generally sends the referring page along with its request for the new page as part of the HTTP referer section of the request header, and that's how sites track where their visitors come from. So for example, a user would click through to Amazon.com from Dealsite.com, and the request would include an HTTP referer telling Amazon.com that the user was linked from Dealsite.com.
To prevent web sites like Amazon from learning that their traffic came from your site, prevent your links from sending the HTTP referer. In HTML5, just add rel="noreferrer" to your links, and then referral information will not be sent to the site that was linked. The noreferrer link type is only suppported in new browsers, so I suggest using the knu's noreferrer polyfill to make sure it works on older browsers too.
So far this will prevent referrer information from being sent from 99.9% of your users - the only users that will send referral information will be users that are both using old browsers and have JavaScript disabled. To make it 100%, you could require users have JavaScript enabled to be able to click on those particular links.
Disclaimer: This is not the thorough idea you're looking for. I ran out of space in the comments so posted it as an answer. A couple of possible solutions come to my mind.
Proxy servers: Multiple distributed proxy servers to be specific. You can round robin your users through these servers and and hit Amazon so that the inbound traffic to Amazon from dualist.com keeps revolving. Disadvantage is that this will be slow depending on where the proxy server resides. So not the most ideal solution for an Ecommerce site but it works. And the major advantage is that implementation will be very simple.
VPN tunneling: Extremely similar to proxy server. VPN tunnel to another server and send redirect to Amazon from there. You'll get a new (non dealsite.com) IP from the VPN server of this network and your original IP will be masked
Redirects from user (Still in works) For this one I was thinking of if you could store the info you need from dealsite.com in a cookie and then instruct the host to redirect to Amazon by itself. Hence the inbound traffic to Amazon will be from the users IP and not dealsite.coms. If you need to get back to the dealsite session from Amazon, you could use the previously saved cookie to do so.
Ill add to this answer if I find something better.
Edit 1 A few hours more hours researching brought me to the Tor project. This might be useful but be wary, Many security experts advise against using Tor. See here
I have a Rails 3.0.x app, which displays a page containing the Yahoo Web Player. The player plays an audio file served by the Rails app, the controller that handles the file request uses send_data to send the mp3 file:
send_data content, :filename=>dsLabel, :type=>mimeType, :disposition => 'attachment'
(*) I've also tried disposition inline
This works fine on Safari, IE, and FF. However, in Opera you click the play button and the audio never plays, Yahoo's code is minified and a bit difficult to tell exactly what's wrong, but I've concluded this isn't javascript problem as far as I can tell.
One thing to note about the site is that when I'm locally on the same network at work, our DNS server resolves the site to a 10.x.x.x LAN IP, otherwise it resolves to a public IP.
In Opera if I open Preferences and add the hostname under Trusted Websites->Secure Internal Hosts then reload the page the audio plays fine. If I change my DNS to OpenDNS it also plays fine. I seem to be hitting a Opera security policy issue that I don't fully understand.
It seems to me that although internally my host resolves to a LAN IP, once loaded Opera thinks its a public site, and so the MP3 won't download, however it too resolves to the LAN IP so it doesn't seem like a public/private divergence.
I was hoping someone in the Stackoverflow community with better understanding of Opera security could explain the policy I'm seeing enforced here.
You may have ran into a "network type pinning" policy. Basically Opera will try to remember whether some site first resolved to a public or private IP.
This policy is meant to guard against attack where a site first sends you some code, then later re-configures itself to claim its IP address is internal. Say, attack.example.com serves a page that links to attack.example.com/intranet/menu.js , later when you re-visit attack.example.com pretends its IP is 10.0.0.1 where your intranet is running, and your intranet also happens to reference an /intranet/menu.js file. If menu.js now runs from cache it can do whatever it wants to on the intranet site. Attack completed.
Hence, Opera may not be applying the security policy according to what IP you're currently connecting to, but according to what IP it first saw the hostname resolve to. Sorry that this is a pretty obscure piece of state, but you're in a pretty small minority when you have some hostname that might resolve either to a private or a public address ;-)