21–30 of 59 posts
I was wondering if an additional cookie based security token is possible with secure_link module. (show image only if session cookie is present) Apparently, it is possible, great! One of the google results: https://gist.github.com/hilbix/5921589
Secure_link module shouldn't be used for anything security related. I think it uses plain md5 and without even an hmac.
This is a cool little project showcasing some of NginX's lesser known modules in action. However, I have one nitpick. The caching server's main location is a bit of a cargo-cult unoptimization. They have specified: location ^/(.+)$ { When the equivalent: location / { Is shorter, clearer, and does not incur a regular expression capture on every request that is never used.
I (I'm not the author) shamefully do some cargo cult Nginx because I don't understand how the location matching really works. My ideal web server would have a configuration that resembles a decision procedure in a programming language, so I can have a mental model for what makes it choose one route over the others, and how settings are combined, etc. Somehow Nginx repeatedly makes me and my coworkers very confused—ar…
I highly recommend this document to start, which describes how NginX processes a request: http://nginx.org/en/docs/http/request_processing.html
For getting the mental model right, you have to understand that NginX configuration is declarative, like SQL or PROLOG. That means as opposed to an imperative or procedural language you might be more familiar with, in NginX you describe "what" you want to have handled, not "how" and NginX worries about the "how" under the hood, for the most part.
Of course like any abstraction it sometimes breaks and leaks, but this is practical software we're talking about. One specific big headache for people is when using "if" in NginX, which is a decidedly imperative construct! As such you do have to tread lightly with it; observe If Is Evil: https://www.nginx.com/resources/wiki/start/topics/depth/ifis...
I found the nginx native image library completely inadequate a few years ago, so I had to use the perl module to connect it to imagemagick libraries instead. Much higher quality results. Not sure if they have improved the native library but I doubt it has the flexibility. The important part is caching the results because of the expensive cpu time. ps. googling about the current state of this came up with an interesti…
We ended up using Thumbor, which was able to give us much better looking images (but at the cost of being extremely difficult to deploy on the CentOS 6.x servers we had at that time).
This is a cool little project showcasing some of NginX's lesser known modules in action. However, I have one nitpick. The caching server's main location is a bit of a cargo-cult unoptimization. They have specified: location ^/(.+)$ { When the equivalent: location / { Is shorter, clearer, and does not incur a regular expression capture on every request that is never used.
The difference is that the last one also matches requests to "/", while the regex ensures that there is at least a single character after the "/". That allows "/" to be used for other purposes, e.g. redirecting to the main page of the site, or displaying a nice error page. (However, in this case it simply shows the default Debian Nginx installation page: http://m.charlesleifer.com/ )
location = / {
# Just whatever happens for "/" requests goes here
}
location / {
# Every other requests ends up here
}We use varnish in front of nginx
Earlier quoted context omitted.
I stopped using varnish because, after all, my site is just a blog and Nginx is just fine for my needs. It has a single backend server, so there's no load-balancing. Basically, I was already using Nginx to serve static files, and my caching logic was so simple it was actually easier to move it into Nginx.
Perhaps better a better question is why you were using Varnish in the first place? I'm genuinely curious because I've never stood up Varnish before so maybe there's an anti-pattern / gotcha to learn from.
His setup is vulnerable to hash length extension attacks: secure_link_md5 "my awesome secret $uri"; This means anyone can extend the URI (eg. adding "/../../../some/other/file" at the end of the filename) and compute a valid key, and force the server to access an arbitrary image file on the backend. If the backend is a private server not publicly accessible, then this may be a security issue. This is why in the ngx_h…
[0] https://en.wikipedia.org/wiki/Hash-based_message_authenticat...
http://lh4.ggpht.com/sTP-3BqnirkHm40qfb496w85A1bf7BpeXthFJ92...
http://lh4.ggpht.com/sTP-3BqnirkHm40qfb496w85A1bf7BpeXthFJ92...