I am writing a backend for my Flutter app using Aqueduct. I have Aqueduct set up so that Nginx proxies requests to it like this:
server {
root /home/web/my_server/web;
index index.html index.htm;
server_name example.com www.example.com;
location / {
try_files $uri $uri/ =404;
}
location /api {
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://127.0.0.1:8888;
proxy_http_version 1.1;
}
...
}
In Aqueduct I serve the files using a FileController:
router.route("/api/v1/app/*")
.link(() => LogController(context))
.link(() => FileController("public/app/")
..setContentTypeForExtension('apk', ContentType('application', 'vnd.android.package-archive')));
However, any files that it returns don't include the Content-Length header. That means that I can't show download progress.
I tried creating a custom FileController where I added the headers in manually:
final contentLengthValue = file.lengthSync();
return Response.ok(byteStream,
headers: {HttpHeaders.lastModifiedHeader: lastModifiedDateStringValue,
HttpHeaders.contentLengthHeader: contentLengthValue,
'x-decompressed-content-length': contentLengthValue,
HttpHeaders.cacheControlHeader: 'no-transform',
HttpHeaders.acceptRangesHeader: 'bytes'})
..cachePolicy = _policyForFile(file)
..encodeBody = false
..contentType = contentType;
The Content-Length header was still removed, but the x-decompressed-content-length header remained so this is a possible workaround. It just doesn't play nicely with some Flutter plugins that look for the Content-Length header and don't have a convenient way to check other headers.
Is this an Aqueduct problem or an Nginx problem? How do I solve it?
This solution works, but it skirts around the original problem. That it, it allows you to serve files that have the Content-Length in the header, but it doesn't explain why it was getting stripped in Aqueduct. Other answers are welcome.
Rather than have Aqueduct serve files, just have Nginx serve them directly.
If you can't change your API route, you can just give it an alias in the Nginx config location block. Add this before the /api location block.
location /api/v1/app/ {
alias /home/web/my_server/public/app/;
}
Now files in the app/ folder will get served by Nginx rather than Aqueduct. Nginx includes the Content-Length header in the files it returns.
Related
What I want is to restrict access to files for unauthorized user.
PocketBase documentation says I can retrieve the file URL and access files through it. The example URL for a file would be like this:
http://127.0.0.1:8090/api/files/example/kfzjt5oy8r34hvn/test_52iWbGinWd.png
I can prevent unauthorized users to get this URL, but authorized users can share URL with other one.
Any ideas?
I found a good way to secure files with nginx, by adding an extra location for my PocketBase server block and using an extra backend with one endpoint.
So, my nginx looks like this:
server {
listen 80;
server_name example.com;
location /api/files {
proxy_intercept_errors on;
error_page 404 = #fallback;
proxy_pass http://127.0.0.1:5000;
}
location / {
proxy_pass http://127.0.0.1:8090;
}
location #fallback {
proxy_pass http://127.0.0.1:8090;
}
}
Where my expressjs backend working on port :5000 checks JWT and responds with 404 if it is valid. Nginx will redirect to :8090 (PocketBase) if 404 returned on :5000.
I've the below nginx conf file to redirect all the requests (by default) to /auth (of my service) and then get back a response header (foo_id). This header will be forwarded to the original request URI triggered by user. The below works properly with the nginx.
...
location /
{
auth_request /auth;
auth_request_set $foo_id $upstream_http_foo_id;
proxy_pass $request_uri
proxy_set_header X-foo-Token $foo_id;
root html;
index index.html index.htm;
}
location /auth
{
internal;
proxy_pass https://myhost/myservice;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
But I need the corresponding ingress rules/annotations that are required to achieve the above use case. I couldn't get the respective auth/proxy-pass related annotations. Kindly help out.
You can use Nginx Ingress Annotations to achieve this goal.
In nutshell:
Assuming, you have an external auth service, which has a Kubernetes service configured.
You need an annotation, which sends auth requests to this service:
nginx.ingress.kubernetes.io/auth-url: http://auth-service.<NameSpace>.svc.cluster.local/auth
Also, you can use nginx.ingress.kubernetes.io/auth-snippet annotation to set your custom configuration for the auth request e.g.
nginx.ingress.kubernetes.io/auth-snippet: |
auth_request_set $foo_id $upstream_http_foo_id;
proxy_pass $request_uri
proxy_set_header X-foo-Token $foo_id;
If you need to return some headers on successful auth, you can use nginx.ingress.kubernetes.io/auth-response-headers:
nginx.ingress.kubernetes.io/auth-response-headers: X-Auth
And, nginx.ingress.kubernetes.io/auth-signin to specify the custom error page
When doing curl -ILk http://192.168.0.4/app the Location header of the 301 redirect is http://my-srv.local/app/ which is a server-local address. I've put server_name_in_redirect on everywhere to get rid of it, but the result is the same.
Config:
server {
server_name my-nginx;
server_name_in_redirect on;
set $endpoint http://my-srv.local;
location / {
server_name_in_redirect on;
proxy_pass $endpoint;
}
}
Note: the nginx version that I'm using doesn't have absolute_redirect yet.
Reference: Information leak with automatic trailing slash redirect
How to make it point to the correct URL or prevent the leak at least?
So it's the my-srv.local who generates that response (that is pretty reasonable). With the nginx 1.11.8+ it will probably generate relative redirects. In the meantime, the possible fix is to overwrite that redirect:
server {
server_name my-nginx;
set $endpoint http://my-srv.local;
location / {
proxy_pass $endpoint;
proxy_redirect $endpoint http://$host;
}
}
I'm trying to build a single page app that utilizes HTML5 App Cache, which will cache a whole new version of the app for every distinct URL, thus I must redirect everyone to / and have my app route them afterward (this is the solution used on devdocs.io).
Here's my nginx config. I want all requests to send a file if it exists, redirect to my API at /auth and /api, and redirect all other requests to index.html. Why is the following configuration causing my browser to say that there is a redirect loop? If the user hits location block #2 and his route doesn't match a static file, he's sent to location block #3, which will redirect him to "/" which should hit location block #1 and serve index.html, correct? What is causing the redirect loop here? Is there a better way to accomplish this?
root /files/whatever/public;
index index.html;
# If the location is exactly "/", send index.html.
location = / {
try_files $uri /index.html;
}
location / {
try_files $uri #redirectToIndex;
}
# Set the cookie of the initialPath and redirect to "/".
location #redirectToIndex {
add_header Set-Cookie "initialPath=$request_uri; path=/";
return 302 $scheme://$host/;
}
# Proxy requests to "/auth" and "/api" to the server.
location ~* (^\/auth)|(^\/api) {
proxy_pass http://application_upstream;
proxy_redirect off;
}
That loop message suggests that /files/whatever/public/index.html doesn't exist, so the try_files in location / doesn't find $uri when it's equal to /index.html, so the try_files always internally redirects those requests to the # location which does the external redirect.
Unless you have a more complicated setup than you've outlined, I don't think you need to do so much. You shouldn't need external redirects (or even internal redirects) or server-side cookie sending for a one-file js app. The regex match for app and api wasn't quite right, either.
root /files/whatever/public;
index index.html;
location / {
try_files $uri /index.html =404;
}
# Proxy requests to "/auth" and "/api" to the server.
location ~ ^/(auth|api) {
proxy_pass http://application_upstream;
proxy_redirect off;
}
I was writing a RESTful applicaiton in PHP and enabled DELETE, PUT requests for nginx.
location / {
root html;
index index.php index.html index.htm;
dav_methods PUT DELETE;
}
When I executed a REST Request with method DELETE, which I wanted to handle inside my index.php - nginx removed the html folder.
What is the right way to tell nginx to pass DELETE requests to my index.php ?
Nginx does not disable PUT or DELETE requests, but it does not allow these requests on a folder index. There isn't really anything that needs to be enabled with nginx (you should remove the dav_methods line), but you need to avoid accessing your index.php through the index directive like:
index index.php index.html index.htm;
Instead use try_files to match the index.php file ie like:
try_files $uri /index.php$is_args$args;
In this case nginx wont complain about your DELETE method.
NginX executes those HTTP methods (DELETE, PUT) directly without even invoking PHP engine because they are handled by the DAV extension inside nginX.
To overcome the issue, you may use POST HTTP method for all of your API calls, but add additional custom header to indicate the actual REST method - instead of this
PUT /api/Person/4 HTTP/1.1
Host: localhost:10320
Content-Type: application/json
Cache-Control: no-cache
you will invoke this
POST /api/Person/4 HTTP/1.1
Host: localhost:10320
Content-Type: application/json
X-REST-Method: PUT
Cache-Control: no-cache
and then in PHP you will check in this way
if($_SERVER['HTTP_X_REST_METHOD']!='')
switch($_SERVER['HTTP_X_REST_METHOD'])
{
case 'PUT':
...
break;
case 'PATCH':
...
break;
case 'DELETE':
...
break;
}