i wanna use node js on my webpage, which is hosted by a company. I saw that you can run a local server on node js, but does anyone know how i can link it to my existing domain example.com.
As mentioned I saw that you can use express for this, but i dont know my port neither how my server reacts to my js code.
any recommendations?
To be able to access your locally developed node project from your domain name from any computer connected to the internet you will need to do something like the following:
Point your domain's DNS records to your server
Log into your domain name provider and find the DNS settings section, then paste in your servers IP address. Once this is done, visiting your domain name in the browser will connect the domain to your server which you control. Under the hood the browser can now successfully ask the domain name server (keeps records of domains and associated IP addresses) for the IP address to query which corresponds to your domain name. But thats not quite enough yet!
Install a server application on your server
A server is just a normal computer with server software installed which enables incoming requests to receive a response in anyway you define in the configuration of the server software. nginx, apache and express are all types of server software.
At this point you need to see whether the server you are renting supports nodejs as a server, if not you should look elsewhere for a provider that does. (not hard to find)
Install software dependencies to get your express server up and running.
EG:
node, npm, express
I make a web app so you can vote for the employee of the month for a supermarket, but they must be able to vote via their phone, I have created a database on mongoDB and host via Github Pages, my problem is that the database of votes does not receive the request when I try to vote via my phone, it works perfectly when I vote via Wifi but not via phone data.
the app is written in html and uses form tag, and javascript for everything else.
Github Pages hosts static pages from a GitHub repository.
That works well for apps that don't require any backed server; you can even do fairly complicated things in them (like write a Morse-code teaching app).
However, you're using MongoDB—that's a database. So you have a system that probably looks something like this:
[user] -> [webpage hosted on GitHub pages] -> [MongoDB database]
That database needs to be hosted at a location that is accessible to the GitHub pages page you load in your browser. GitHub pages is hosting your web pages in a place that's accessible anywhere in the world (which you know, since you're reading the pages on your phone over data). But if that database isn't accessible anywhere in the world, your webpages will fail to reach the database.
What URL are you using to reach your database?
I would guess it looks something like localhost:####, or some local IP (like 192.168.12.34:####). These addresses are accessible on your local network (your wi-fi), but not globally. When you connect over data, your webpages try to send data to your MongoDB instance at some IP address that doesn't exist on the cellular network. If that's the case, you need to think about hosting your database somewhere that can be accessed anywhere in the world, from any network. You can do that by exposing your MongoDB publicly (through port forwarding, etc), but that's almost certainly the wrong thing.
Instead, you probably want to set up a managed MongoDB instance—pay a service a few $ a month to host your database for you; you'll get an IP address or a domain name for your database that you can use. If you were to start writing an app in 2005, you would probably been told to pay for a VPS (Virtual Private Server) which is basically a computer with its own IP address; you could host your MongoDB on that VPS, and even serve your webpages with Apache or NGINX. That would cost about $5/month today. You could also buy a domain name for the VPS.
Apologies if this entirely misunderstands your problem, and also if this is more detail than you were looking for. Setting up a database-backed application isn't as easy as it could be.
I'd like make cordova app in javascript with traceroute to another ip/domain. I can detect my IP in device with server side script in PHP which gives me back my IP address to my javascript app script. But is it possible to trace my server or another ip from javascript in device app?
I found this traceroute cordova plugin, but there is no information how can I use it.
https://github.com/navidmalekan/cordova-plugin-traceroute
Anybody with same problem? Thanks a lot for help
Unfortunately a proper traceroute command requires the use of ICMP. JavaScript does not even have the ability to create raw TCP or UDP sockets (instead it creates WebSockets and WebRTC connections which abstract these two with some added security around establishing the socket), and it certainly doesn't have the ability to send ICMP messages.
That isn't to say that all hope is lost, but you won't get a perfectly accurate traceroute with 100% accuracy. If your goal is to find the route taken from a JavaScript client to your own server, you can instead have your server initiate the traceroute to the client and assume that they use the same path in reverse to reach you. This isn't always true, but it's usually fairly close.
If your goal is to find the route taken between two JavaScript clients, then this requires even more guesswork. Your server can initiate a traceroute to each client, then figure out what the common path is. For instance:
Server -> ClientA
192.168.1.1
100.100.100.100
200.200.200.200
123.123.123.123
75.75.75.75
Server -> ClientB
192.168.1.1
100.100.100.100
200.200.200.200
180.180.180.180
150.150.150.150
In this case we can surmise that the path 192.168.1.1 -> 100.100.100.100 -> 200.200.200.200 is the path that your server takes to exit its Autonomous System and that 123.123.123.123 is the entry-point to ClientA's Autonomous System and 180.180.180.180 is the entry-point to ClientB's Autonomous System. Therefore a traceroute from ClientA to ClientB may look like:
75.75.75.75
123.123.123.123
180.180.180.180
150.150.150.150
Of course this isn't guaranteed to be accurate. There may be an alternate path through ClientA's internal network that puts them closer to ClientB, so they may use a different entry-point. Still, it's better than nothing.
Regarding Cordova
Cordova is a framework for creating mobile applications (Android apps) using HTML, JavaScript, and CSS. Unlike operating in a browser where you're limited to the DOM API and a few other HTML5 APIs, Cordova grants you access to the full Android system via a custom API. This way you can access their SD card, camera, microphone, etc.
Cordova is able to perform a traceroute not because it's JavaScript, but because it's Android. The JavaScript is actually making a call (via an API) to an external program written in either Java or C/C++ which makes the traceroute
If you are creating a mobile application and not a website, then this may be an option for you
I am very confused about ip addresses and headers. So I'm sorry if my question seems simple.
I have gone through the answers listed here:
How to get the user IP address in Meteor server?
But I can't figure out how to make them work. For example, I am trying to use this:
Meteor.onConnection(function(conn) {
console.log(conn.clientAddress);
});
But nowhere can I find where to place it.
If I place it on the client side it says Meteor.onConnection is undefined. If I place it on the server nothing happens. I don't think you run it on meteor.startup.
Is there someone could give me a hand in explaining where to use this code? Specifically if anyone has built a custom tracking system, that would be great. Do you store ips into database? or how to record for tracking purposes?
Any hint will help! thanks
Place the code anywhere on the server. e.g. in server/main.js. There is no need to call it from within Meteor.startup.
Start the app.
Open your browser to the appropriate address (e.g. http://localhost:3000) - this will cause a web client to connect and run the code from (1).
Look at your shell output (the shell you used to start the app - not the browser console) and you should see your local IP address (127.0.0.1) printed.
This should work in production as well, however if your app is served behind a proxy (e.g. nginx) you will need to add the appropriate commands to pass the user's IP to your app. For nginx, see this post.
I have a desktop product which uses an embedded webserver which will use self-signed certs.
Is there something that I can put in a web page that would detect that they haven't added the root CA to their trusted list, and display a link or DIV or something directing them how to do it?
I'm thinking maybe a DIV that has instructions on install the CA, and a Javascript that runs some test (tries to access something without internal warnings??), and hides the DIV if the test succeeds. Or something like that...
Any ideas from the brilliant SO community ? :)
Why do you want to do this? It is a bad idea to train users to indiscriminately install root CA certificates just because a web site tells them to. You are undermining the entire chain of trust. A security conscious user would ignore your advice to install the certificate, and might conclude that you are not taking security seriously since you did not bother to acquire a certificate from an existing CA.
Do you really need HTTPS? If so, you should probably bite the bullet and make a deal with a CA to facilitate providing your customers with proper CA signed server certificates. If the web server is only used for local connections from the desktop app, you should either add the self-signed certificate to the trusted list as part of the installation process, or switch to HTTP instead.
Assuming you know C# and you want to install a pfx file.Create a exe that will be run from a url.Follow this URL
and this
The only idea I have is to use frames and some javascript.
The first element of the frame will act as a watchdog waiting x amount of time (javascript setTimeout) before showing your custom ssl failure message to the user with hyperlinks or instructions to download the self-signed cert.
The second frame element attempts the https connection and if successful resets the watchdog frame so that it never fires. If it fails (assume https cert validation failed) the watchdog message would then fire and be presented to the user.
Depending on your browser you will most likely still see some security warning with the approach but you would at least be able to push your own content without requiring users to run untrusted code with no proper trust chain (This would be much much worse from a security POV than accepting the cert validation errors and establishing an untrusted ssl session)
Improvements to the concept may be possible using other testing methods such as XMLHttpRequest et al.
You should not do this. Root certificates are not something you just install, since adding one could compromise any security given to you by https.
However if you are making a desktop app then just only listen to 127.0.0.1. That way the traffic never leaves the users computer and no attacker can listen in.
You might try to add some (hidden) Flex element or Java Applet once per user session.
It will just download any https page of your server and will get all information about connection:
com.sun.deploy.security.CertificateHostnameVerifier.verify()
or
javax.security.cert.X509Certificate.checkValidity()
I suppose Flex (which is more common to users) shoul have similar ways of validating https certificate from user's point of view. It should also share OS' trusted cert. store while Java might have its own.
Since the server is running on the client machine (desktop product) can it not check the supported browsers for installed certs using winapi/os functions? I know Firefox has a cert database in the user's profile directory and IE probably keeps information in the registry. It wouldn't be reliable for all browsers but if the server simply chooses between "Certificate Found" and "Please ensure you have installed the cert before continuing" then no harm is done as the user can choose to continue either way.
You could also simplify matters by providing an embedded browser as well (ie, gecko), this way you only have 1 browser to deal with which simplifies a lot of things (including pre-installing the root CA).
To recap: you are setting up webservers on desktop apps; each desktop will have its own webserver, but you want to use SSL to secure the connection to that webserver.
I guess there are several problems here with certificates, one being that the hostname used to access the desktop has to match the certificate. In this case you have little choice but to generate certificates on the client. You'll need to allow the user some way to specify the host name in case the name used by outsiders can't be detected from the host itself.
I'd also suggest allowing for an admin to install a trusted cert, for those who don't want to rely on self-signed certs. This way you can also offload the cost of trusted cert maintenance to the admins who really want it.
Finally, in my experience browsers either allow or refuse the self-signed cert and there is no way for the server to know if the cert is denied, or temporarily accepted, or permanently accepted. I assume there must be a mechanism somewhere to handle SSL failures but typical web programming doesn't operate at that layer. In any case, the only thing a webserver can do if SSL fails is to fallback to non-SSL, and you've indicated in a comment that you can't have anything non-SSL. I think you should try to have that restriction lifted; a non-SSL start page would be extremely helpful in this situation: it can test (using frames or images or JSON or AJAX) the https connection, and it can link to documentation about how to set up the certificate, or where to download an installer for the cert.
If the browser won't connect because of a self-signed cert, and you're not allowed to use plain HTTP at all, by what other means could you communicate with the user? There are no other channels and you can't establish one because you don't have any communication.
You mentioned in a comment writing a win32 app for installing the cert. You could install a cert at the time you install the application itself, but that doesn't help any remote browsers, and a local browser doesn't need SSL to access localhost.
We've been working on an opensource JavaScript project, called Forge, that's related to this problem. Do you have a website that your users could access? If so, then you could provide a secure connection to those desktop apps via your website using a combination of Flash for cross-domain + JavaScript for TLS. It will require you to implement some web services on your website to handle signing certificates the desktop app certificates (or having your desktop apps upload the self-signed certs so they can be accessed via JavaScript). We describe how it works here:
http://blog.digitalbazaar.com/2010/07/20/javascript-tls-1/
An alternative to setting up a website, but is less secure because it allows for a MiTM attack is to host the JavaScript+Flash directly on the desktop app server. You could have your users hit your desktop app over regular http to download the JS+Flash+SSL cert, but then start using TLS afterwards via the JS. If you're on a localhost connection the MiTM attack might be a little less worrisome -- perhaps enough for you to consider this option.
An ActiveX control could do the trick. But I really didn't chime in to help with the solution, more to disagree with the stance that what you are doing is a security risk.
To be clear, you are needing a secure cipher (hopefully AES and not DES), and are already in control of your endpoints, just not able to completely rule out promiscuous-mode network sniffers that could catch clear-text passwords or other sensitive data.
SSL is a "Secure Socket Layer", and by definition, is NOT dependent upon ANY certificates.
However, all effective modern ciphers require it to authenticate the tunnel endpoints, which is not always a necessity for every application; a frustration I have dealt with in numerous back-end datacenter automation routines using web service APIs to manage nodes, where the "users" were actually processes that needed encrypted key exchange prior to a RESTful command negotiation.
In my case, the VLANs were secured via ACLs, so I really "could" send clear-text authentication headers. But just typing that made me throw up in my mouth a little bit.
I'm sure I'll get flamed for typing this, but I'm extremely battle-hardened and would've made the same comments to you in years 10-15 of my IT career. So I empathize with their worries, and very much appreciate if they are passionate enough about security to flame me. They'll figure it out eventually.....
But I do agree with the fact that it is a BAD idea to "train" users to install root CA's on their own. On the other hand, if you use a self-signed cert, you have to train them to install that. And if a user doesn't know how to determine if a CA Cert is trustworthy, they definitely won't be able to determine a self-signed cert from a CA Cert, and thus either process would have the same effect.
If it were me, I would automate the process instead of having it assist the end-users, so that it becomes as hidden from them as possible, just like a proper PKI would do for an enterprise.
Speaking of which, I just thought of a potential solution. Use the Microsoft PKI Model. With Server 2012 R2, you can deliver trusted keys to endpoints that are not even domain members using "device control" via "workspaces", and the client machines can subscribe to multiple workspaces, so they are not committed solely to yours if they subscribe. Once they do, and authenticate, the AD Certificate Services Role will push all root CA Certs necessary, as are present in active directory, or specified LDAP server. (In case you are using offline CA servers)
Also, I realize this thread is like 7 years old, but am sure it still gets referenced by a good number of people needing similar solutions, and felt obligated to share a contrasting opinion. (Ok Microsoft, where's my kickback for the plug I gave you?)
-cashman