Currently working on an app where I authenticate and set the auth properties of a user in a middleware (to be used in the route). These auth properties are stored in res.locals.user.
I was wondering if the api caller could access and log the res.locals variable after the request is sent back. From what I've read it doesn't seem like the case but I want to be sure.
I've seen answers refer to the request/response lifecycle so any resource on that would also be greatly appreciated.
Thank you
res.locals.user is local to your server and local to the code processing that specific request. The sender of an incoming http request has no access to that data.
If you want to share anything in that with the sender of an incoming http request, then you can write your code to include something from there in the response you are sending back as the http response or if you are using an html template engine, then you can code the template to include anything you want from res.locals.user.
Server-side variables are only available on the server unless your code specifically sends them back to the client. And, things in the req or res object are only available to that specific request while it is being processed. Once the request processing is over and your code for processing the request is done, then those specific req and res objects will be garbage collected and they are not reachable from other requests.
Related
req.params property
We can call a DELETE request by using the req.params.id by gathering URL parameters for pointing to a record by its id for example to a backend route /users/delete/id/:id
req.query property
We can call a DELETE request by using req.query.id for extracting a JSON object and send it to a backend route /users/delete?id=2 to the controller/model for a record to be deleted like
{"id": "2"}
Question
What is the safest way for sending data to DELETE requests in terms of security issues that a user may take advantage of directly or indirectly considering we already have a safe login system?
If you were using GET or POST then the URL and body (if it wasn't JSON) might be vulnerable to CSRF attacks, but you can't trigger a DELETE request with cross-origin code (unless explicitly granted permission with a perflight CORS request).
You aren't, so it doesn't make any difference (at least from a security perspective).
I am making a chat program.
I am using an Nginx server and NodeJS.
I have setup a websocket via ssl and that works fine.
I have decided to use cookies for authentication.
There are two functions which are crucial:
mconnection.prototype.make_server_https=function(){
console.log('Make server https');
var cthis=this;
var server_https=modules.https.createServer({
key: this.ssl_key,
cert:this.ssl_cert,
ca:this.ssl_ca
},(request,response)=>{
console.log('### CreateServer ###');
console.log('CreateServer, Request:');
console.log(request);
console.log('CreateServer, Response:');
console.log(response);
console.log('######');
and
mconnection.prototype.make_server_websocket=function(){
var server_websocket=new modules.ws.Server({server:this.server_https});
var cookie = require("cookie");
var cthis=this;
//whenever a new client connects with the server.
server_websocket.on('connection', function(client_socket, request){
console.log('### On Connection ###');
console.log('OnConnection, Client Socket:');
console.log(client_socket);
console.log('OnConnection, Request:');
console.log(request);
console.log('######');
If I do state the port number in the client url,function make_server_https gets run and inside there i can access the cookie and set it via the response object.
but in the original url,function make_server_websocket gets run, and there i have access to the client_socket on the server. But there it seems i dont have access to the cookies.
I need to client_websocket to start the connection with this given client. And I need to tie it somehow with the cookies login information.
But i never have both at the same time so i dont get how i could connect them to make the login happen.
I am probably misunderstanding something, any help in the right direction would really be appreciated.
you have to serve you index page from node server using GET then when the request reaches backend you will have response object which can then be used to SET-COOKIE if not set from backend.
And after GET request is complete COOKIE will be added in browser, when next request is made for websocket connection COOKIE will be added to the request in REQUEST HEADERS by the browser which will be available in backend through request object.
And if you decide to use it in login system then you can SET-COOKIE on successfull login.
i got it. its an event called on headers, not on connection. and there i can just push onto the headers.
I've a JS (Angular) client that makes a PUT request (REST API) to server and server sends back a large payload that I'm not using in the client currently.
Is there a way to just fire the request and ignore any response that comes back? The main need here is to avoid the data cost incurred by receiving that payload. I've looked at closing the connection once the request is fired, but am not sure if that's the best way to handle this.
If able, I think the only way to change this would be to change the api endpoint to not include a payload from the put request.
I'm assuming you are using angular's http class and using Observables. But even if you aren't, your angular client is going to need to read the response status sent back from the server to determine whether or not the put request was successful or not. In order to read the status, you'll need to response, and unfortunately the full response sent from the server.
You could close the connection right after the request, but as I've mentioned you'll have no way of knowing whether or not the request was successful.
To ignore the request just don't do anything if the request is successful.
If you don't want the request to exist at all then do it on the backend.
In express.js we often attach objects to the req object in middleware, e.g. req.myObject. What prevents a user sending an http request that includes req.myObject already set to some value? For example, I could use req.myObject as part of authentication. Could a user set req.myObject = true when sending a request when it should really be false? Potentially an issue if req.myObject is set on some routes but not others but middleware that checks req.myObject is re-used across routes.
req is an object created by Express when a request is received. It's not something passed directly from client to the server, in fact it isn't even available to client.
A client can only relay information to the server in some limited ways - GET query, POST form data, or route paths which are attached to the req object by Express as req.query, req.body, and req.params respectively.
Anything else attached to the req object is out of scope of the client, at least directly.
Related question: Node.js request object documentation?
I know this has been asked countless times, but none of the answers I found described the actual connection to backend.
I have a one-page JS app that communicates with small backend (Django) API. I use session based authentication. User info is cached on first load. If session expires, I need to change page header and flush user info from cache. However, most of my API resources are public and return always 200. Several other resources are private and return 403 if user isn't logged in, which is great as this gives me excatly the information I need. The problem is, some pages access public resources only. In case session is suddenly deleted on backend and user navigates to url that accesses only public resources, user info isn't flushed and I have an UX problem.
My initial idea was to request private user resource (let's call it /users/self/) on every url change which returns 200 in case user is authenticated and 403 in case they aren't. This however requires 1 extra request before every other request for each url change, which isn't really ideal.
Are there any easier techniques I could use in this case? I don't mind even switching to other type of authentication if that would solve the problem.
What i have done and seen for such scenarios is to use some type of http interceptor that intercept all http requests done by Angular and if it finds a response status of 401, such interceptors raise an event using $rootScope.
See one library here https://github.com/witoldsz/angular-http-auth
To use it, one needs to subscribe to the events raise using some type of root controller, which can redirect the user to login page.
See an example here https://medium.com/opinionated-angularjs/7bbf0346acec
Instead of sending a additional auth request, just check in your backend in every request, if the session didnt expire. If the user is not auth, then return a status code.
In angularjs we used a httpResponse interceptor, who intercepts every response and checks against this status code.
Your backend could add a header to the response if the user is still logged in, regardless if the requested resource is public or not. The client can then check the presence of that header and act accordingly.
On both sides this is done with some kind of filter or interceptor. In angular this would be a $http interceptor.
We at work do what others have already told you: use an HttpInterceptor.
We have every response sent from our backend structured in the same way: an object with two fields: a responseCode and the actual response. We vary the responseCode according to what happened in the backend, being success, security alert, or authentication required for that given action the most common cases.
Then the interceptor reacts in the appropriate way according to each responseCode we have defined. In the case of an authentication required, we redirect to the login page, you could do whatever you need. It's working great for us.