I am just starting to learn nodeJS, and also following socket.io basic-chat tutorial.
I have questions, I'm sure they sound ignorant, but I really want to understand them:
1) nodeJS "listens" on localhost:8080 for example. But let's say I want the socket.io chat to be on a specific page: localhost/chat.html, how do I make that chat system to work on localhost/chat.html, and not on localhost:8080
(so that a user clicks on "chat.html" link and the chat server starts only when in that page)
2) For the chat, I want to allow only users who are registered and logged-in to be able to view that localhost/chat.html page. With PHP I would simply check if a session is set using isset $_SESSION and get the id of the user from that session, how can I get the session started by PHP, with the nodeJS file?
how do I make that chat system to work on localhost/chat.html, and not on localhost:8080
The default port for HTTP is 80. http://localhost/ implies http://localhost:80/. If you want, you can have Node.js listen on port 80.
(so that a user clicks on "chat.html" link and the chat server starts only when in that page)
Well, that part of the question is nonsense. The server needs to be running so it's available to receive a request when it comes in.
With PHP I would simply check if a session is set using isset $_SESSION and get the id of the user from that session, how can I get the session started by PHP, with the nodeJS file?
PHP sessions typically work via a cookie. You can use cookies in your Node.js application as well. To make this easier on yourself, consider installing Express, and one of the many session data handlers that plug into it as a module.
Related
I know it's kind of awkward question, but is it possible to start up an express server on the browser (basically run an express server on client's side i.e. when user clicks on a button) of an Angular app?
The server on client's side would be very simple, basically define a route that would be later used by the app. (like a local call - 127.0.0.1/myRoute)
Has anyone ever seen anything like that?
Thanks.
Is there a way to do the following in a SPA:
Add User
Update list of users, for all other logged in users, with the added user if they are in the User List Module of the application. Do this without a chron job constantly checking if there is a new user.
Almost like forcing a response without a Request. Is this a Unicorn?
I am trying to see if there is an efficient way of doing this.
Technologies are NodeJS, Express, and React on the client.
You could try setting up a websocket connection between your logged in users and your server. That way, you would be able to push a change (like a new user being added) to all your clients. However, all the clients would still need to be constantly online. Try looking into socket.io as a gentle introduction to websockets.
You could also try looking into WebRTC and other P2P web technologies, though I'm not sure if that would help you in any way.
now I am learning how to build single page web applications with node.js. When I come to the communication part between server and client, I am confusing about the difference between http post request and web socket communication
Here is my understanding:
Web socket like socket.io is asynchronous communication while POST is synchronous communication method.
socket.io is mainly used in dealing with real-time task like html games or dynamic online chatting, or boradcasting some informations.
for validating forms when some user sign up for certain website, it is really good to check instantly if the user name is already been taken or not, I think it is using socket.io to achieve that.
for example in a login page, after I press the username and password, then press 'login' button, I could just use emit things in socket.io to transfer a JSON file with these information. when we checked these information and send back a flag string like 'true' or 'false ' to indicate if the login is success or not.
So my question is:
Why we still use HTTP POST for login and signup ?
Is socket.io better than HTTP POST ?
Why not replace HTTP POST with socket.io ?
P.S for some large files, I have not go into these parts, so I have no idea.
Here is some additions:
After reading a similar question I find I seem to assume that WebSocket is a replacement for HTTP. It is not. It's an extension.
I think this asnwered my third question Why not replace HTTP POST with socket.io.
I have a node.js app which routes events to a web page's "shotbox" which is similar to a chatbox on the home page. This shoutbox requires a sessionVar and sessionId that changes based on your browser, session_id, and some other things. I have been successful in getting these variables from my browser, but if I close that browser page, my node.js app no longer works. I assume this has to do with a keep-alive header or something (i'm not sure, I don't know all that much about http to be honest). I want to have my node.js app be free from needing the browser up at all. I'm thinking I could, upon starting up the node.js app, login into the site, and retrieve these custom variables. But how do I achieve the same effect that the browser accomplishes when staying open?
Basically, how do I implement a keep-alive browser session in node.js?
The browser session is supposed to end when you close it, that's expected behavior. Your app shouldn't care if anywhere between 0 - [huge number] of sessions are active at any given time; it sounds like something really basic is wrong with your server. Post some code...
I'm thinking about exploring the idea of having our client software run as a service on a high port and listen for simple http GET requests from 127.0.0.1. The theory is that I would be able to access this service via js from a web page that is served from my site.
1) User installs client software that installs itself as a service and waits for authenticated requests on 127.0.0.1:8080
2) When the user hits my home page js on the page makes an xhtml request to 127.0.0.1:8080 and asks for the status
3) The home page then makes another js request back to my web server sending the status that it received.
This would allow my users to upload/download and edit files on a USB attached device in real-time from a browser. Polling could be the fallback method which is close to what we do today.
Has anyone done this and what potential pitfalls are there? Will this even work?
I can't see any potential pitfalls. I do have a couple of points however.
1/ You probably want to make sure your service only accepts incoming connection from the local machine (127.0.0.1). Otherwise, anyone could look at your JavaScript and figure out that it's talking to [your-ip]:8080. They could then try that themselves from a remote site (security hole).
2/ I wouldn't use port 8080 as it's commonly used for other things (alternate HTTP servers, etc.). Make it configurable and choose a nice high random-type value.
3/ I'm not sure what you're trying to do with point 3 but I think you're trying to send the status back to the user. In which case, why wouldn't the JavaScript on your home page just get the status in a single session and output/update the HTML to be presented to the user? Your "another js request back to my web server" doesn't make sense to me.
You may not be able to do a xml http request to 127.0.0.1 as XMLHTTPRequest is usually limited to the same domain as the main content is being served from. I'm not sure if this restriction applies if the server is on the client's machine. That being said, you could still create a <script> tag that had the src pointing to 127.0.0.1, and have the web server return some Javascript to run. If you only need a simple response, this could work well.
I think it is much better for you to avoid implementation of application logic in JavaScript and html. Once user clicks button on a web page JavaScript should send request to your service and allow it do the rest of the work.
You could have problems with step 1 (Client installs itself) depending on your target user base.
You will need a customised install for each supported environment (Win2K, Vista, Linux, MAC OS 9.0/10.0 etc.).
If your user is on a locked down at work PC this simply wont be allowed.
To some users this might look distressingly similar to a trojan unless you explicitly point out you will be installing software that runs as a service.
You didnt mention an unistall procedure. Users resent "Adobe" like software which installs itself and provides no sensible un-install options
Ohterwise the approach is sound, and, there are are couple of commercial products out there that use exactly this approach!