My question is a NodeJS newbie question. I would like to somehow detect if a user is accessing my network (Wifi) and I would like to indicate the users presence in my network.
How would I go about identifying the user presence. I'm completely clueless as I was unable to find any library that could help me detect this in Node. Is this even possible? If so could you point me to the appropriate libraries and the approach that I need to use.
If you run a router like a Linksys, etc. that can support DD-WRT, you can flash that firmware and then use either SNMP or web page scraping to get connected clients. There are node.js libraries for SNMP and there are a ton of examples of web page scraping with Node.JS.
Alternatively, you could get really complicated and add in RADIUS authentication to your DD-WRT installation and watch for an authentication event.
Another option, you could send ICMP (Ping) packets to every potential address that your router would acknowledge. e.g. if it's 192.168.1.1 on a 255.255.255.0 subnet, you would have 253 addresses to ping. Of course, the connecting user's machine would have to have ICMP responses turned on (which they typically do by default).
I hope one of these suggestions helps.
Related
I need to get the serial number or some information that doesn't change from the user's device, I thought about getting IPV4 but depending on where the user is it can change and all the logic I tried to implement didn't work, I'm doing it in an MVC project .net 6.0 and this logic I'm trying to implement in C# but it would be possible in JavaScript I would also use this information to automate the user's login, using a security device already pre-registered by him
Disclaimer: I work at Fingerprint.
I would also use this information to automate the user's login, using
a security device already pre-registered by him
It might be a good idea to use a browser identifier (fingerprint/visitorId) as a decision point for further choices (e.g. whether to challenge a user with another factor or put some additional barriers). It's not a good idea to use a fingerprint/visitorId as a password replacement. There might be falsy results and this technology is not intended to replace passwords.
Moreover, I'd like to correct some misconceptions from the question and comments.
but from what I saw in the documentation to implement it, you need to
register an SSL address
Open source FingerprintJS is a pure client-side library. There are no HTTP APIs, servers, or requests. You don't perform any Subdomain setup whatsoever.
The Subdomain setup and SSL certificates are related to the Fingerprint Pro, it's a different service (take a look at Pro vs open source comparison). The Subdomain setup improves accuracy among other benefits. You can try the service on localhost without it. Moreover, with the Subdomain setup, you can develop your app on localhost without any limitations as well.
It will generate a hash unique to the browsing device
This is not correct, they are not unique at 100% cases. The accuracy of the open source FingerprintJS is ~60%. The accuracy of Fingerprint Pro is ~99.5%. Nevertheless, there might be some false positives/negatives. This is the main reason why it's not a good idea to use fingerprint/visitorId as a password replacement.
The question is fairly self explanatory. I want to auto-detect my server software within a local network from a webpage. I'm able to send and receive broadcasts with node, but for this to work I need to be able to send or receive broadcasts with in-browser javascript, and then connect directly to my server.
Does anyone know how to do this? Is there a library for it, or am I out of luck?
I would heartily recommend that you take a look at coreos/etcd, hashicorp/consul or some other service discovery solution which exposes an HTTP interface and JSON data about the location of your services.
Since you cannot access the underlying networking devices from the browser (imagine if I could start probing SO's internal network from my external location), arguably, it takes as much time to set up as it would for you to write a proper Node.js application to discover resources on your network and expose these via JSON to your clients, but using proper service discovery solutions means you can take this to any kind of networking configuration your applications may be running in tomorrow under any kind of circumstances they might find themselves in whilst running (fiber optic cables got cut out between two centers, something hard fell down and broke the switch, something monopolized all the network bandwidth, the IP address of the service changes intermittently, etc.).
I am writing a simple javascript game for a webpage. I am going to convert it to the desktop using tidesdk. I would like to allow players on different machines to play each other without the need to communicate through a server.
Is this possible in general? Is this Sockets?? Do you have any links of this being done with javascript code?
Is this possible with TideSdk? Do you know of any links to examples of this being done wiht TideSdk?
How do the players know what ip address/port their machine is on so they can give it to the other player?
I am sorry these are vague and open questions, but I don't really know where to start looking for this stuff, as I don't really know what the stuff I am looking for is called.
... Oh, and I don't want to use any third party stuff if I can help it. Maybe the jquery at a push.
This would be impossible with the APIs provided by web browsers (you would need to use something like Socket.IO and communicate through a server, as others have said). Fortunately, since you are using TideSDK, it is possible as long as you don't need a lot of network efficiency. You will need to provide a server, but it will not have to be powerful enough to host the actual games.
The General Client and Server Method
There are other ways to organize a network, but you can look those up if you think they'd be easier to implement.
Your server will host the actual game download and provide matchmaking capabilities. The clients that people download will contact this matchmaking server to find others who want to play.
The matchmaking server should select one of those clients to be a host for the others. Finally, the matchmaking server will tell the client selected as a host that it is the host and give it everyone's connection information (ports and IP addresses) while giving the other clients the connection information for the selected host. The host will connect to the other clients.
The host computer will be the only one that actually does any processing of gameplay, and the other clients just display whatever information the host sends them. The clients render the current state of the game from each player's perspective on their respective computers and capture user input, which is sent to the host for processing.
Implementation
TideSDK provides a Ti.Network.TCPSocket object which can make raw TCP client connections to TCP servers. Unfortunately, it does not also provide a way to make raw TCP servers. Instead, TideSDK provides a Ti.Network.HTTPServer object, which implements the HTTP protocol server over TCP, and a Ti.Network.HTTPClient object, which provides an HTTP client (it is actually just an abstraction over the normal AJAX request API). You can use the provided HTTP server on the host computer and directly connect to it on the clients using the provided HTTP clients. Data will be exchanged using the HTTP protocol. As far as I can tell, this is your only option here.
I did not find any example code out there (beyond what is in the TideSDK documentation) but you might find some if you are really interested.
Next Steps
If I wanted to go ahead with using TideSDK, I would do the following:
Tell the developers of TideSDK that you are interested in a TCP server socket. A raw TCP connection would be much faster than HTTP.
Test out the HTTP connection and find out if it is fast enough for my game.
Yes it's possible in general, and sockets are what you need. Although I don't think it's possible in practice, here's why.
Normally in a P2P game, there would be a server that knows who is online, and what their IP is. When new players connect to the server they will see a list of other users, they can select who they want to play.
Without having the server, there will be no way for users to see who is online, and to answer your 3rd question:
How do the players know what ip address/port their machine is on so they can give it to the other player? It doesn't matter if they can find their own IP, they have no way to find the IP of the opponent (without calling them on the phone :)).
So, if you want to build a game, then you'll need a server. I suggest Node.JS alongside Socket.IO
Introduction: I want to develop the chat client that user can chat on the browser and I use the protocol call xmpp. Because of HTML5 web socket not yet available I try flash xmlsocket instead.
Problem: I cannot connect to the server via browser. I'm not sure why, but I think that it is the problem of the server configuration.
Question: Which is the best jabber server suitable for this job?
Most probably this is a permission issue. Either that or you've just configured the wrong host/port to connect to. Flash is not allowed to connect to other hosts than the one it was gotten from itself. You have to explicitely allow flash connections on the receiving side of the request (so on the chat server that you are connecting to). Google for crossdomain.xml to get more info.
ejabberd sounds like a suitable option for you. ejabberd is xmpp server written in erlang and is used quite widely. Many of the well known web based im services like www.meebo.com etc are known to be running on ejabberd. It allows you to install other transports which would let you enable talking to users of other protocol like yahoo, msn, icq etc.
You can also have a look at the xiff action script library by ignite realtime. It is an xmpp client library in action script. If you use this library you would just need to implement the ui components.
Hum... flash is ok, but you'd be better of using something like BOSH, which is basically an HTTP layer over XMPP.
Ejabberd would be a good server, as it supports BOSH, I don't know about OpenFire or Tigase (but I'd say they do). Other servers should be looked at carefully because they don't seem to have a "dynamic" community.
You will need a lot of Javascript, and for that, I can recommend StropheJS, which is probably the very best library out there today.
We have created a MUC (Multi-user chat room) client called Aristochat that works in the browser recently at Superfeedr. You can find the code on Github and an example here.
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