I have searched a lot and still couldn't find a solution, I am using nodejs with express which is setting etag to true by default, I tried all of the solutions i found online and it is still set, examples:
res.set('etag', false);
res.removeHeader('ETag');
app.disable('etag');
app.use(express.static(__dirname + '/public'), { etag: false });
And still it is set, so, is there something i am missing here since i am not really that experienced in node or express.
My question is obviously, how to disable this header, because, I have a page with a lot of images (A LOT) and all of them are static and etag is causing a lot of blocking since it's sending requests to check validity and preventing the browser from relying on cache-control, which is hugely increasing page load time.
Thanks for the help
Refer to: http://expressjs.com/4x/api.html#app.set
You can do it in ExpressJS 4 using:
app.set('etag', false);
Setting it to false disables the etag header altogether while the default is set to true.
Possible option values are:
Boolean (true,false)
String ('strong', 'weak')
Function
This is not a full answer but I am adding it just in case anyone faces the same issue.
It turned out what I was missing is that the browser forces a cache validity check on first load (including page refresh), and that's why I kept seeing the etag header.
To properly test if the header is removed you have to browse to the url and check not go directly to it.
I hope this helps someone, because it took me a while to find it out
Related
We have a cluster with 3 servers with Load Balancer in front (CloudFlare). Things worked well when we had 2 servers (A & B) in the cluster but after we added a 3-rd server (C) we noticed few odd things.
One of them is quite important and I do not understand how it happens at all.
Our web application makes AJAX requests to itself in order to get some JSON data back and if requests hit new server (C) response looks like that:
{
code: 404,
text: "Not Found",
message: "Database context not allowed."
}
Our application does not throw such error and so I searched in google a bit and noticed that it's mentioned on: OpenNTF XPagesExtensionLibrary
However, we do not use XPages at all so I wonder how could it be that our AJAX requests somehow involve that logic.
Any suggestion & tip would be appreciated.
UPDATE
The backend code of my agent is not important (it could be also an empty agent, I checked), because the request does not come to my agent.
The AJAX call is triggered by jQuery
let url = "domain.tld/api/key";
let params = {"a": 1};
$.post(url, params, function (data) {
// some code
},
"json"
).always(function() {
// some code
});
The URL, which I suspect is an issue starts with /api/key and I believe it's an issue (because all other ajax calls where endpoint do not start from /api/ work well).
Thanks.
Figured that our with help from comments (which you can see under my original post).
Apparently there is DAS servlet that handles all requests starting from /api/* and it runs if XPages engine is loaded.
In my case the 2 servers out of 3 have XPages shut down so the issue happened only on 1 server.
The solution would be:
Shut down XPages (or find a way to shut down DAS).
Alternatively change a URL from /api/path to something else (this is what we will do).
recently in one of my applications I needed to access currently logged-in user data for saving in another model (something like the author of a book or owner of a book). in my googling, I encountered these references but none of them was useful.
https://github.com/strongloop/loopback/issues/1495
https://docs.strongloop.com/display/public/LB/Using+current+context
...
all of them have this problem about accessing context or req object. after three days I decided to switch to afterRemote remote hook and add Owner or Author on that stage.
but something was wrong with this solution.
in strongloop's documentations (https://docs.strongloop.com/display/public/LB/Remote+hooks) there is a variable as ctx.req.accessToken that saves current logged-in user access token. but in the application this variable is undefined.
instead, I found accessToken in ctx.req.query.access_token and it was currently access_token variable that is sent to the server.
here is my problem:
is this variable (ctx.req.query.access_token) always available or
it's just because loopback-explorer send access_token as GET
variable?
in production mode do applications need to send access_token as
GET variable or it should be sent as Authorization in the header?
why ctx.req.accessToken is undefined?
could these things change over time? cause most of users encounter this problem due to deprecation of app.getCurrentContext()
Is this variable (ctx.req.query.access_token) always available or
it's just because loopback-explorer send access_token as GET
variable?
Well if your application always sends in the querystring, then it'll be always available for you, but it also sent in the header, or cookie or in the request body, but I don't suggest using it because it if the user logged in and the access token is valid and ctx.req.accessToken should be available and you can use it.
In production mode do applications need to send access_token as
GET variable or it should be sent as Authorization in the header?
I believe Authorization header is preferred, as if you send it in a GET variable, well it'll be visible in the logs and someone with the access to the logs can access the session(well unless you trust everyone), other than this it's fine to have it in a GET variable. Though I believe loopback client SDKs(Angular, Android, iOS) all send it via Authorization header by default, so you might have to configure them(maybe not possible).
Why ctx.req.accessToken is undefined?
Sometimes the context is lost thanks to the database drivers connection pooling, or the context req is lost(ctx.req) and they are null.
Assuming ctx.req is defined(because sometimes it's not), then probably that means the user is not logged it, or it's access token wasn't valid(expired or not in database). Also it could be a bug(maybe misconfiguration on your side), which also means for you that you will authentication problems.
Could these things change over time? cause most of users encounter this problem due to deprecation of app.getCurrentContext()
app.getCurrentContext is risky to use and I don't suggest unless you have no other solution. If you use it and it works, it might stop working if the database driver changes or in some corner cases that you haven't tested it, it might not work.
In the updated doc https://loopback.io/doc/en/lb3/Using-current-context.html
add this in your remoting metadata
"accepts": [
{"arg": "options", "type": "object", "http": "optionsFromRequest"}
]
then
MyModel.methodName = function(options) {
const token = options && options.accessToken;
const userId = token.userId
}
but it says
In LoopBack 2.x, this feature is disabled by default for compatibility reasons. To enable, add "injectOptionsFromRemoteContext": true to your model JSON file.
so add "injectOptionsFromRemoteContext": true on your model.json file
The app I'm working on has a controller that issues templates to the front end (single page app). It's very basic, and simply consists of
#path = params[:path]
render template: "templates/#{#path}", layout: nil
Here my concern however is the direct use of the users input. Everything about this to me feels like it can be attacked with something as simple as path traversal. The route for this is
get "/templates/:path.html" => "templates#file", constraints: { path: /.+/ }, defaults: { format: 'html' }
I've tried multiple things to attempt a path traversal attack, such as
request /templates/path/to/../somewhere/else.html
request /templates?path=/path/to/../../something.rb
request /templates/index.html?path=/path/to/../../config/something.html
request /templates/path/../../../file.html
Fortunately, I haven't had any success with this. The requests that just start with /templates and don't specify anything after it, don't match the route thanks to the constraint so that is good.
It seems as though when that route is matched, rails doesn't allow you to override the path parameter through a url parameter, so I don't seem to be able to inject it there.
The ones that interest are the first and last examples above, where rails seems to internally be changing the requested URL before invoking the routes file. When I request /templates/path/to/../somewhere/else.html, my console output shows a request for /templates/path/somewhere/else.html. When I make a request for /templates/path/../../../file.html, the log shows a request for /file.html.
Am I missing something somewhere that will leave the app open to security issues, or is this just rails being sensible and protecting itself for me?
UPDATE
I've done some more digging, and if I try doing some URL encoding then I can cause the server to simply not respond at all. If I request /templates/%2e%2e%2f%2e%2e%2f%2e%2e%2ffresult.html then I just get an empty response with a connection: close header.
I assume that the parameter parser higher up in the rack is checking all urls for this type of attack? Regardless, my original question still stands. Am I missing something here?
I can not for the life of me find any documentation regarding the possible properties of varnish (version 3) objects.
We know (from googling, varnish documentation just mumbles and leaves you more frustrated) for example that the request object has the url property (req.url) and also that it has req.http.X-Forwarded-For. But has anyone ever in any way found... say... a list?
Thanks!
/joakim
You can't really give a comprehensive list of things like req.http.X-Forwarded-For because req.http.* are HTTP headers. The Cookie header of a request will be req.http.Cookie and the User-Agent header will be req.http.User-Agent. There are a lot of standard headers, but you can set any arbitrary header and it will show up in req.http.___________. You can see the headers of the HTTP response in resp.http.*. Same for backend response in beresp.http.*.
All of the other properties are listed here: https://www.varnish-cache.org/docs/3.0/reference/vcl.html#variables
In my node.js express app I'm submitting a form, to an action on a controller.
All this controller does is:
send(req.body)
(I'm using RailwayJS (but that's not all that important to this question I don't think)
I'm doing this is to get the values in the form
However, it comes back as 'Forbidden'
If I restart node, and refresh the page (confirming i want to post back) then I get the desired result...
Any idea how to get the values of the form without restarting?
I think this is related to 'protect from forgery' beforeFilter. Do you pass authencity_token to your post?
Possible solution: skipBeforeFiler('protect from forgery'); -- it disables CSRF protection
Better solution: use form_for helper, or pass authencity_token manually. Check apidocs to learn more about CSRF protection: http://jsdoc.info/1602/express-on-railway/helpers.html#instance/csrf_tag