Good afternoon,
I come to request support here to try to understand a behavior that I have noticed in my application and that I cannot explain the reason why it happens.
Settings
I'm using Webshepere, version 9.0.0.11, in which a spring mvc application is running over HTTPS in a profile. This application performs the definition of values in session (HttpSession), so that later, through the JSP, it is possible to obtain this data to be displayed in the browser.
On the client side, through js, a connection is made via WebSocket. The WebSocket server is located in another WebShepere profile.
Unexpected behavior
Whenever the websocket connection is successfully performed, all session data is deleted. Only the data that was recorded after successful connection is kept.
Additional data
If the WebSocket Server is installed in the same profile, the reported behavior no longer occurs, and the application works as expected.
if the application uses HTTP, the behaviour isn't presente.
on wildfly server, even with HTTPS, the behaviour is as expected, that means that session data isn`t deleted.
Default configuration
Application Address: https://myappurl:9444/
webSocket Server address: wss://myappurl:9450/websocket
After tests carried out, it was found that as the connection to the websocket was made to another port on the same domain, an override of the cookies was being carried out, thus eliminating the session data.
The solution went through, in the webshere's profile where the websoket server is located, changing the parameterization of the cookie name in the session management, from the default (JSESSIONID) to (JSESSIONIDA).
Path: Application servers > server1 > Web container > Session management > Cookies
Related
I am trying to build an app to retrieve data from a local database, The structure of the app that I have a mobile app, server(on a hosting service), and local server(on my pc), I am trying to make the mobile app request data from the server via a normal HTTP request then the server request the data from the local server but the problem that I could not be able to connect with my local server I believe that I could not connect to my local server because my local server does not have a public IP, so I am trying to find a better way to achieve my idea.
I read something about Websocket but I don't know if it suitable for my idea beacuse it is Bi-directional connection and It most used for chatting app
I want to build the app with NodeJs, so what should I do to implement this idea, and thank you for the help.
Each server is on a different network the main server is on Heroku host and the local server is on my personal computer
Life would be a lot easier for you if you move your local server to Heroku where they can much more easily and securely talk to one another.
You can't connect from your Heroku server to the server on your private local network because it is behind a firewall in your home router. To allow such a connection, you have to configure a known public IP address for your home network (that won't change or use DDNS if it can change) and configure port forwarding in your firewall/router so incoming connections from the internet on a specific port can reach your local server. You will then have to harden your local server against random internet attacks since it will then be open to the internet.
One other possibility is that you could have your local server connect to your Heroku server (perhaps with a webSocket connection using some sort of secret credential). Since your Heroku server is already reachable from your home network, this would require less networking configuration change. Depending upon what you're trying to do between the two servers, you could either have the local server just make a regular http request to the Heroku server (either sending data or asking for data) or you could make a webSocket connection and then data can be sent either way of the webSocket connection.
Preamble: I understand that there were quite a few similar questions on SO that ask the same thing. All of them are about different implementations of the idea, or use other languages and platforms, and didn't answer my question.
I have a website running at https://sub3.domain.edu/page_x and a WebSocket server running at https://sub1.sub2.domain.edu/page_y (names obviously changed for privacy). Both addresses belong to domain.edu, which is my university website.
Currently, users will login to my website at the first link using basic HTTP auth. The actual authentication, i.e. checking the username and password, is handled by an Apache module on the first server only.
Right now, no authentication is needed to connect to the WS server, which makes it open to DDOS attacks (the WebSocket server performs CPU intensive work for every connected user). I merely connect like this:
ws = new WebSocket ('wss://sub1.sub2.domain.edu/page_y/wss')
My goal is to figure out how to use the first website's authenticated session to connect to the second server. How do I modify the website to send something (like a token) that my WebSocket server can recognize as an authenticated user and then allow access? The WebSocket server is a node.js app running at the address I specified above.
I cannot install the Apache module used on the first server since that can only be done by the university IT department, who will not do it for a self-administered machine. I don't want to move the website to the second server because I would really like to use the university Apache module, since it is the same authentication used for all university apps, and we would prefer that our users don't have to remember another password for our site.
If you can ask the owner of SITE 1 (where the apache module exists) to share the cookies across the two subdomains See How do browser cookie domains work? for detailed explanation
If the subdomain is rightly set, once user is logged in with SITE 1, SITE 2 will have the cookie set too.
You then have two options on SITE 2 server side.
Option 1 - Site 2 (server side) needs to be able to validate cookie of SITE 1. (you need to share the secret by which SITE 1 creates the cookie and sets it when reading on your side.
Option 2 - Site 2 (server side) can communicate internally with SITE 1 (/check-cookie ('true-false')
Whether you use Option 1 or Option 2 , You need to integrate answer from Websockets token authentication using middleware and express in node.js and listen to the upgrade event on your server side (SITE 2) to check the cookie on http upgrade connection on websocket handshake. blocking access if it is not authenticated cookie invalid using option 1 or option 2.
i've created a project(asp.net) - website
The database resides on the client machine.
Flow:
Client opens the website, and submit with the required fields, and then the server would authenticate.
Next, the api what i've created should be transferred to the Client pc, as the database would be accessible only where the client and server at the same system only.
Limitation: cannot move the database to the server, ie making database on the server.
If i'm hosting website on the localhost, everything is running fine, and also m fetching data from the database and i can see it on the browser.
But the same if i'm hosting website on server, m not able to fetch any result.
Is there any method or so, to execute on the client system that would be making connection between the cient browser and database residing on the client system only.
The whole scenario is same as of: bloomberg (what i came to knw about my issue and the bloomberg as a public db to be used issue), where bbg restricts its usage on the web, and bbg is accessble only for the client system for the client n on that client account only.
ON STRAIGHT: is it possible to access the client machine database or an application by browser.
Because i after making opening the website and also making some input and then submit, the call should call api which will access the data to be shown on browser would be from the client pc.(lets say - database resides at client pc)
No, there is no way to access a traditional database on a PC directly from the browser. You'd need a web app in the middle, so that your browser accesses the web app, and this offers indirect access to the database.
If you can install a web app that has access to the PC database, there are interesting ASP.NET and browser technologies to access the data: Web API OData + breeeze.js.
The only alternative would be to use HTML5 Storage databases, but they are still under definition and mostly unsupported. See, for example, this page: HTML5 Features: Storage. An this is not what you're looking for.
I'm creating an app where the server and the clients will run on the same local network. Is it possible to use web sockets, or rather more specifically, socket.io to have one central server and many clients that are running native apps
? The way I understand socket.io to work is that the clients read the web-pages that are served from the server but what happens when your clients become tablet devices running native apps instead of web pages in a browser?
The scenario I'm working with at the minute will have one central server containing a MEAN app and the clients (iPads) will make GET requests to the data available on the server. However, I'd also like there to be real-time functionality so if someone triggers a POST request on their iPad, the server acknowledges it and displays it in the server's client-side. The iPad apps will (ideally) be running native phonegap applications rather than accessing 192.168.1.1:9000 from their browser.
Is this technically possible to connect to the socket server from the native apps or would the devices have to send POST requests to a central server that's constantly listening for new 'messages'? I'm totally new to the whole real-time stuff so I'm just trying to wrap my head around it all.
Apologies if this isn't totally clear, it's a bit hard to describe with just text but I think you get the idea?
Correct me if I am wrong.
You have multiple iPads running native app. They send a POST request to your node JS server which is running in a computer in the same local network. Whenever the server receives a request from app, you want to display that a request has been received in your computer screen.
If my assumptions about the scenario is correct, then it is fairly easy to do. Here are the steps to do it.
Create a small webpage (front end). Load socket IO in the front end page like this -
<script type="text/javascript" src="YOUR_SERVER_IP/socket.io/socket.io.js"></script>
Then connect to server using var socket = io(). This should trigger connection event in your backend.
Handle all POST request from apps normally. Nothing special. Just add a small snippet in between. socket.emit('new_request', request_data). This sends new_request event to front end.
Handle the new_request in your front end using socket.on('new_request', function(request_data) { ... });. That's it. No need to add anything to your native app for realtime update.
The second step would be a little complicated as it is necessary to make socket variable available inside all POST requests. Since you chose node.js, I don't think you need any help with that.
Not totally clear on your project, but I'll try to give you some pointers.
An effective way to send data between native apps and a server is using a REST server. REST is based on HTTP requests and allows you to modify data on the server, which can connect to your database. The data returned is typically either JSON or XML formatted. See here for a brief intro: http://www.infoq.com/articles/rest-introduction
Android/iOS/etc have built in APIs for making HTTP requests. Your native app would send a request to the server, parse the response, and update your native UI accordingly. The same server can be used from a website using jQuery ajax HTTP requests.
Express.js is more suited to serving web pages and includes things like templating. Look into "restify" (see here: mcavage.me/node-restify/) if you just want to have a REST server that handles requests. Both run on top of node.js (nodejs.org).
As far as real-time communication, if you're developing for iOS look into APNS (Apple Push Notification Service). Apple maintains a persistent connection, and by going through their servers you can easily send messages to your app. The equivalent of this on Android is GCM (Google Cloud Messaging).
You can also do sockets directly if that's easier for you. Be careful with maintaining an open socket on a mobile device though, it can be a huge battery drain. Here's a library for connecting ObjC to Socket.IO using websockets, it may be useful for you: https://github.com/pkyeck/socket.IO-objc
Hope that helps!
To answer your question, it is definitely possible. Socket.io would serve as the central server that can essentially emit messages to all of the client. You can also make Socket.io listen for the messages from any of the clients and serve the emitted message to the rest of the clients.
Here's an example of how socket.io can be used. Simply clone, npm install, and run using 'node app.js'
All you have to do is to provide a valid server address when you connect your socket from the iPad clients:
var socket = io.connect( 'http://my.external.nodejs.server' );
Let us know if you need help with actual sending/receiving of socket events.
It is possible to connect to Websockets from your apps.
If you are using PhoneGap then you need a pluging that gives support to websockets in your app (the client) and then use websocket like normal way using Javascript see this.
If your app is native iOS look into this it could help you.
The primary use of the Sockets in your case is to be a bidirectional "pipe" between an app and server. There is no need of server sending the whole web-page to the native app. All what you need is to send some data from server to the client(app) in response to POST (or GET) request and then using this data on client side to update client's UI in real-time. If you are going to use moderate amount of devices (say tens of them), you may have connected all of them to the server permanently keeping individual socket connection open for every individual link server-to-app. Thus you may deliver data and update client's state in real time.
In fact web browsers also employ sockets to communicate to web servers. However as in general case there is no control on amount of concurrent clients in Internet, for the sake of limited networking resources conservation, servers do not keep sockets open for a long time, closing it just after the web-page was sent to client (or timeout has expired). That's how HTTP protocol works on the low level. The server waiting for the HTTP clients (browsers) by listening the 80 port, responding them by sending the whole web page content, then closing the connection and keep waiting for another requests on the same port.
In your case it's basically a good idea to use socket.io as it's a uniform implementation of sockets (ok WebSockets) on both client and server side. The good starting point is here
I'm developing an application using sails in which I have to connect from external sources. they can be IOS or android mobile applications or simply an external html client.
In that regard I cant't use sails helper methods to make web sockets request be handled by controller actions.
as I read through the sails.io client file i figured I could just use.
socket.emit('get' , {url:'/tomato' , data:{message:'pony'}} , function(response){});
to mimick the sails socket.get() function but it is not working.
sails log in terminal shows the following message : No session data returned, and an error was encountered saving session data for the first time: undefined.
Sorry you had to give up! This is a fairly common issue that comes up around communicating via sockets with a 3rd party. It actually has nothing to do with the Sails helper functions, and your usage of socket.emit to replicate the socket.get functionality is perfectly valid . Unfortunately the error message for this case is (clearly) broken in Sails v9, but the gist is: you need to get a cookie from the 3rd party domain before you connect the socket. This means making a JSONP request to that domain. Socket.io can actually do that for you, although you may have to set io.util.ua.hasCORS = false manually before calling io.connect. Or you can create a JSONP endpoint on the remote server and hit it yourself. Either way, once you have that third-party cookie in place, the socket handshake should work fine and allow perfect communication between your site and the Sails server.
Edit
The io.util.ua.hasCORS method is not valid, as it turns out--it will cause a JSONP request to be made to the remote server, but the response won't have a cookie attached so it's not going to get the job done. However, when the next version of Sails is released it will include a mechanism to request a cookie from the external domain, and will handle the connection automatically in the background within sails.io.js. Also note that you need to set authorization to false in the /config/sockets.js file in your Sails app in order to allow sockets to connect from remote domains.