after some reasearch
knowing websocket is lighter than https method post and get
however in term of security, post is more secure than websocket.
as i could still use web socket even my server restart(logged out)
in this case, i found that i couldnt check if that particular user is authenticated user or not.
or maybe im wrong.
please correct me.
im using express js and https and i had done some action using https post.
(in here socket automatically using secure connection as https) but the problem is authentication
so my question here is.
i want to turn them into websocket as its lighter.
can web socket check if the one sending is authenticated and session is still active(e.g logged out user cant emit)?
or should i stick with https post?
if there is a way to authenticate emitted socket(from client to server)... please share with me here
thanks alot
instead of doing another authentication,
i had found something nice here and its works.
https://www.codementor.io/tips/0217388244/sharing-passport-js-sessions-with-both-express-and-socket-io
i could use existing passport authentication on my socket
note: since im using mongodb
then i do not use radis.. instead i use mongostore for the session store from npm connect-mongo
hope this will help other
Related
I have wrote a simple Django web service that provides an iOS app with JSON information containing download links.
I don't mind the JSON information to be clear text, but when the user logs in, I would like him to login with his username and password, then he would probably get some kind of key for future requests which I understand that can be sniffed out. For that first interaction, how could I protect the password and username from being clear text and sniffed?
I have decided I wanted to use a symmetric encryption to encrypt my password and have that key both on client and on server. (yes, I am aware that if someone goes to the trouble of binary hacking my app and sniffing packets from a customer he would be able to get the password in clear text, it's just not a likely concern).
I would like to use some kind of encryption that I can easily do in iOS and than decrypt in my django server. anyone has a suggestion on how to do that?
If you want to encrypt the communication between your django server and the client then you can use secure HTTP rather than plain old HTTP. This is done outside django, and is configured at the web server level. For example, if your django app is ran by a WSGI server like gunicorn or uWSGI which in return is handled by nginx (this is a common setup) then you would configure your nginx server to accept only secure HTTP requests and forward any standard http request to https. This way you can ensure that everything the client sends to the server is encrypted on the browser prior to sending. Similar setup is done with Apache, though I personally have never used Apache with django.
Since the OP feels that HTTPS is not a viable option a modification of CHAP Challenge-Handshake Authentication Protocol for the initial key creation might be an option.
I am making an application where I want to have a sign-in within the ruby client app which is supposed to connects to a Ruby on Rails server. This is similar to what you do in applications such as Dropbox. The user somehow provides their username and password, and the ruby program should connect to the server establishing a session. After the initial sign-in I need to transfer data between the client and server (potentially a lot). I have looked at web-sockets for this, however I can't find a way to set this up properly.
The Rails server uses Devise for authentification, and I would prefer to keep it that way if possible.
I have not been able to figure out how I can set up this connection. Any hints for where I should start looking?
If you want to have a 'persisten' connection between your client and server, I suggest you use something like 0MQ socket which a kind of 'super-socket 'library with bindings for ruby. On the server side, you would 'bind' to an IP/port, on the client side you would 'connect' and then you could use a connection type of REQ/REP (Request/Response). If, at any time the client disconnects, this doesn't 'blow' the binding on the server side. If the server side disconnects, this doesn't blow up the client side (it just block on waiting for the answer unless you define a timeout).
There are other options also for non-blocking operation between the client and the server.
I know that there are a ton of threads about this. But I'm still confused.
I've got an app that making request to my server(nodeJS) to get JSON-data.
For the moment everyone can get everything at: http://myserver/allUpdates/ with no password. They just have to know the URL.
So I thought I would do it little more secure.
I been looking at Basic Auth, that seems to work by sending username and password in the header for every request.
Is that enough?
Some guys say that it doesn't do much if youre not using SSL. But it must be better than nothing, right?
I've never used SSL and it seems there is a lot to learn.
So my question is, should I bother with auth when I'm not using SSL?
Or are there other alternatives?
Some guys say that it doesn't do much if youre not using SSL. But it must be better than nothing, right?
Unfortunately, those guys are right. Basic Auth is, when sent plaintext, probably worse than nothing as it gives you the vague feeling of some security without any actual security.
This is because it is trivial to intercept network requests through a proxy or similar. If you're not used SSL then every parameter you're sending is easily and readily visible, including your basic authentication credentials.
In answer to your question "should I bother with auth when I'm not using SSL?" - that depends. If you want to ensure your data is only accessed by authenticated users, then it's really SSL or nothing. But if all you're trying to do is reduce the burden on your servers (i.e, rate limiting), then maybe not. I'm going to assume you're looking to do the former, in which case I'd recommend taking the time to get to grips with SSL. There are lots of resources out there about using Node with SSL, depending upon what additional frameworks you might be using (Express, etc).
SSL encrypts your requests, which means that anyone that sniffs your network traffic can't read the payload of the request.
You have two ways to auth the client to the server:
send credentials or an API key with every request OR
login in the client once with credentials or API key and reuse it's session
In both ways, you should use SSL and send the credentials with your POST data.
Situation: Two web servers, and a browser client. The client has an open websockets connection with Server A. Server A decides that this client should really be serviced by Server B.
I would like to know if there is any established technique for performing this hand-over?
It would be great if this could happen as invisibly as possible for my client side code - but I haven't come across any feature which would allow this.
Best I have come up with so far is Server A sending a 'you should really deal with Server X' message, client closing the WS session and then sending some http request which will get routed to the correct server, and upgraded to WS. I can see the presense of load balancers making this complicatied though.
Any thoughts?
From a programming point of view, the socket connection is treated as an open file handle, and that's what you are trying to pass along. For that, I would check out the question "Portable way to pass file descriptor between different processes" for a handful of methods.
But if you are not writing your own web server, and are looking for an off-the-shelf method for Apache, etc, this probably won't help you much.
How can I future-proof my client URL links to my server for future HTTPS migration?
I have a .net winforms client talking to my ruby on rails backend. If I move the website in the future I want to make sure that my API links from the client don't have to change.
Or is this something a hosting provider can let you configure.
Oh, and when I do migrate I will not want any non HTTPS to occur.
PS1 - I am not talking about moving servers here, just upgrading the existing web application server with a certificate and moving to HTTPS only traffic
Place a base url as a config parameter in your client application, then run all new links through a getLinkURL(String relativeDestination) method which will give you a full url.
If you're worried about clients that haven't been updated making non-http requests, in your http (non-secure) vhost just Redirect 301 / https:// on your server.
If I understand the question correctly, I think you can solve this by using relative links everywhere; unless there's a reason you can't do that?
I think you need to look into DNS and how it works. It's not going to protect you against an HTTP to HTTPS migration but would allow you to move servers without re-engineering your code. Ideally I think you'd look to have a config setting in your code to switch from HTTP to HTTPS (and back) when necessary.