i dont know what to say ive searched every where to enable keep-alive on nginx but nothing ,
is there any one to tell me step by step enable it?
webserver: nginx-apache [ custom-build 2 [DirectAdmin] ]
You should increase the timeout of keep-alive in configuration.
Related
Here is sample of Ngrok file which I'm using within tunnel:
authtoken: somevalue
version: "2"
tunnels:
sometunellName
proto: http
addr: 5555
schemes:
- http
- https
host_header: rewrite
request_header:
add:
- "ngrok-skip-browser-warning:true"
log_level: debug
log_format: json
log: ngrok.log
Several common headers didn't give any new result.
The "ngrok-skip-browser-warning:true" header has to be added in the browser as the ngrok cloud side of things has to see it to skip the browser warning. With your config, you've added it in the ngrok cloud so only your app is seeing it.
~ an ngrok employee
I have a question about cors implementation in django.
Having a problem with setting the correct cors values.
My deployment is on docker.
I have a deployed 3 containers:
backend: Django + DRF as backend (expose 8000 port)
Nginx to server my backend (use exposed 8000 port and set it to 1338)
frontend React app used with nginx (uses port 1337)
Everything is on localhost.
I use axios from frontend to call get/post requests. (I call to 1338 port then I think it is redirected to internal service on 8000 port)
For backend I had to install django-cors-headers package to work with CORS.
I think I set up it correctly. But there are scenarios where it does not work.
In settings.py
INSTALLED_APPS = [
...
"corsheaders",
]
...
MIDDLEWARE = [
...
"corsheaders.middleware.CorsMiddleware",
"django.middleware.common.CommonMiddleware",
...
]
Nginx.conf for nginx image:
upstream backend {
server backend:8000;
}
server {
listen 80;
add_header Access-Control-Allow-Origin *;
location / {
proxy_pass http://backend;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host:1337;
proxy_redirect off;
}
location /static/ {
alias /home/app/web/staticfiles/;
}
}
First scenario
In settings.py
CORS_ALLOW_ALL_ORIGINS = True
No get/post requests work. Get message:
CORS Multiple Origin Not Allowed
Second scenario
In settings.py
CORS_ALLOWED_ORIGINS = ["http://localhost:1337"]
Works with get requests, but does not work with post requests.
For post requests:
options with error: CORS Missing Allow Header
post with error: NS_ERROR_DOM_BAD_URI
It works if I am not using nginx for backend.
Adding request headers as requested in the comment.
I am not sure what else could I add here. So my deployed project is here (it also is easy to launch if you have docker on your machine:
https://gitlab.com/k.impolevicius/app-001
I have come across this issue a while back, and I think the issue is with the headers.
In the MDN docs, it is stated here that other than for the simple requests, we'll get preflighted requests with OPTIONS method. There are 3 main headers that we need to send in response in your case
Access-Control-Allow-Origin: http://localhost:1337
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type
From the looks of it you have configured the first header and you should be seeing it in the network tab too, and since the error is about missing allow headers, you need to add Access-Control-Allow-Methods header
to your nginx file
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
Seeing your network tab on the requested headers will give more context here, generally you should be seeing Access-Control-Request-Method and Access-Control-Request-Headers headers in the OPTIONS request. If there are some headers that you aren't allowing, please write an nginx rule for the same. You can look into this solution for more reference
Good day, seems that problem is in axios.post not in Django or nginx.
Because if you do curl post or post from drf browsable api, it works fine:
curl -X POST http://localhost:1337/Country/ \
-H "Content-Type: application/json" \
-d '{"name": "other"}'
{"id":6,"name":"other"}%
But react app generates this OPTIONS request:
app-001-backend-1 | [13/May/2022 05:56:20] "OPTIONS /Country/ HTTP/1.0" 200 0
app-001-nginx-1 | 192.168.240.1 - - [13/May/2022:05:56:20 +0000] "OPTIONS /Country/ HTTP/1.1" 200 0 "http://localhost:1338/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Safari/605.1.15" "-"
I have installed the Varnish with Apach2 and setup that using the HTTP proxy apache module and used the headers to get the Data over HTTP and send it to HTTPS using reverse proxy.
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:80/
ProxyPassReverse / http://127.0.0.1:80/
RequestHeader set X-Forwarded-Port “443”
RequestHeader set X-Forwarded-Proto “https
But the issue I am facing this setup is the Browser error Content is loading from HTTP over HTTPS has been blocked.
Mixed Content: The page at '' was loaded over HTTPS, but
requested an insecure stylesheet ''. This request has been
blocked; the content must be served over HTTPS.
Please help to understand where I am wrong and how can I make this work?
Thank you in Advance.
There's not a whole lot of context about the setup and the configuration, but based on the information you provided I'm going to assume you're using Apache to first terminate the TLS connection and then forward that traffic to Varnish.
I'm also assuming Apache is also configured as the backend in Varnish listening on a port like 8080 whereas Varnish is on 80 and the HTTPS Apache vhost is on 443.
Vary header
The one thing that might be missing in your setup is a cache variation based on the X-Forwarded-Proto header.
I would advise you to set that cache variation using the following configuration:
Header append Vary: X-Forwarded-Proto
This uses mod_headers and can either be set in your .htaccess file or your vhost configuration.
It should allow Varnish to be aware of the variations based on the Vary: X-Forwarded-Proto header and store a version for HTTP and one for HTTPS.
This will prevent HTTP content being stored when HTTPS content is requested and vice versa.
A good way to simulate the issue
If you want to make sure the issue behaves as I'm expecting it to, please perform a test using the following steps:
Clear your cache through sudo varnishadm ban obj.status "!=" 0
Run varnishlog -g request -q "ReqUrl eq '/'" to filter logs for the. homepage
Call the HTTP version of the homepage and ensure its stored in the cache
Capture the log output for this transaction and store it somewhere
Call that same page over HTTPS and check whether or not the mixed content errors occur
Capture the log output for this transaction and store it somewhere
Then fix the issue through the Vary: X-Forwarded-Proto header and try the testcase again.
In case of problems, just add the 2 log transactions to your question (1 for the miss, 1 for the hit) and I'll examine it for you
I want to set up hawkBit (running on server) and swupdate (running on multiple clients - Linux OS) to perform OS/Software update in Suricatta mode.
1/ Follow up my post on hawkBit community, I've succeeded to run hawkBit in my server as below:
Exported to external link: http://:
Enabled MariaDB
Enabled Gateway Token Authentication (in hawkBit system configuration)
Created a software module
Uploaded an artifact
Created a distribution set
Assigned the software module to the distribution set
Create Targets (in Deployment Mangement UI) with Targets ID is "dev01"
Created a Rollout
Created a Target Filter
2/ I've succeeded to build/execute swupdate as SWupdate guideline
Enabled Suricatta daemon mode
Run swupdate: /usr/bin/swupdate -v -k /etc/public.pem -u '-t DEFAULT -u http://<domain>:<port> -i dev01'
I'm pretty sure this command isn't correct, output log as below:
* Trying <ip address>...
* TCP_NODELAY set
* Connected to <domain> (<ip address>) port <port> (#0)
> GET /DEFAULT/controller/v1/10 HTTP/1.1
Host: <domain>:<port>
User-Agent: libcurl-agent/1.0
Content-Type: application/json
Accept: application/json
charsets: utf-8
< HTTP/1.1 401 Unauthorized
< Date: Sun, 16 May 2021 02:43:40 GMT
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: DENY
< Content-Length: 0
<
* Connection #0 to host <domain> left intact
[TRACE] : SWUPDATE running : [channel_log_effective_url] : Channel's effective URL resolved to http://<domain>:<port>/DEFAULT/controller/v1/dev01
[ERROR] : SWUPDATE failed [0] ERROR corelib/channel_curl.c : channel_get : 1109 : Channel operation returned HTTP error code 401.
[DEBUG] : SWUPDATE running : [suricatta_wait] : Sleeping for 45 seconds.
As per a suggestion from #laverman on Gitter:
You can use Gateway token in the Auth header of the request, e.g. “Authorization : GatewayToken a56cacb7290a8d8a96a2f149ab2f23d1”
but I don't know how the client sends this request (it should be sent by swupdate, right?)
3/ Follow up these instructions from Tutorial # EclipseCon Europe 2019, it guides me to send the request to provision multiple clients from hawkBit Device Simulator. And the problem is how to apply this to real devices.
Another confusion is: when creating new Software Module, Distribution on hawkBit UI, I can't find the ID of these, but creating by send request as Tutorial, I can see the IDs in the response.
So my questions are:
1/ Are my hawkBit setup steps correct?
2/ How can I configure/run swupdate (on clients) to perform the update: poll for new software, download, update, report status, ...
If my description isn't clear enough, please tell me.
Thanks
happy to see that you're trying out Hawkbit for your solution!
I have a few remarks:
The suricatta parameter for GatewayToken is -g, and -k for TargetToken respectively.
The -g <GATEWAY_TOKEN> needs to be set inside of the quotation marks
see SwUpdate Documentation
Example: /usr/bin/swupdate -v -u '-t DEFAULT -u http://<domain>:<port> -i dev01 -g 76430e1830c56f2ea656c9bbc88834a3'
For the GatewayToken Authentication, you need to provide the generated token in System Config view, it is a generated hashcode that looks similar to this example here
You can also authenticate each device/client separately using their own TargetToken.
You can find more information in the Hawkbit documentation
Now I am writing a simple server on Go using the standard library net/http. The server is placed in a docker container and placed on google cloud paltform. But when I want to access the server from my third-party React application (which is located on a different server), I always get a CORS error.
Looking for solutions online, I added a library to my code, which is designed to solve the problem of СORS. But adding a library didn’t help. Even after its application, the server does not send me СORS headers. What code do I have now?
package main
import (
controller "./controllers"
"./util"
"github.com/gorilla/mux"
"github.com/rs/cors"
"log"
"net/http"
//"os"
)
// Entry point
func main() {
c := cors.New(cors.Options{
AllowedOrigins: []string{"*"}, // All origins
AllowedMethods: []string{"GET"}, // Allowing only get, just an example
AllowedHeaders: []string{"Authorization", "Content-Type"},
AllowCredentials: true,
Debug: true,
})
r := mux.NewRouter()
// Router
// Live check
r.HandleFunc("/live", controller.LiveCheck)
apiRouter := r.PathPrefix("/api").Subrouter()
// Medication data
medicationRouter := apiRouter.PathPrefix("/medication").Subrouter()
medicationRouter.HandleFunc("", controller.MedicationHeadersList).Methods("GET")
medicationRouter.HandleFunc("/{id}", controller.MedicationChildrenList).Methods("GET")
medicationRouter.HandleFunc("/{id}/leafs", controller.MedicationLeafsList).Methods("GET")
medicationRouter.HandleFunc("/search/", controller.SearchMedicationList).Methods("GET")
medicationRouter.HandleFunc("/result/{id}", controller.MedicationSearchResult).Methods("GET")
//r.Use(util.CORS)
apiRouter.Use(util.VerifyToken)
log.Println(http.ListenAndServe(":8080", c.Handler(r)))
}
Here is the answer I get from the up-point in the browser console:
Request Method: OPTIONS
Status Code: 200 OK
Remote Address: 35.190.37.37:80
Referrer Policy: no-referrer-when-downgrade
Content-Length: 0
Date: Mon, 10 Jun 2019 22:37:36 GMT
Vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
Via: 1.1 google
I also tried to manually set the CORS headers, creating a middleware, but it also did not help.
Thanks in advance for your help!
UPD Thank you all for the answers and help. Everything turned out to be much easier. Google did not update my docker container, so all my changes in the code did not give the desired effect. My code, which I gave in the question description, perfectly solves the problem of the CORS. The question can be considered closed.
I had this problem too. You can use this code in the development environment.
c := cors.New(cors.Options{
AllowedOrigins: []string{"*"},
AllowCredentials: true,
AllowedHeaders: []string{"Authorization", "Content-Type", "Access-Control-Allow-Origin"},
// Enable Debugging for testing, consider disabling in production
AllowedMethods: []string{"GET", "UPDATE", "PUT", "POST", "DELETE"},
Debug: true,
})
How are you testing this? When a browser must make a cross-origin request that fails pre-flight conditions an OPTIONS request gets sent. This OPTIONS request contains a header who's value is the HTTP method being used in the cross-origin request.
I stood up your simplified version of your server and here's some example curl commands and results.
The below request works fine, I've set the Access-Control-Request-Method to GET
curl -I -X OPTIONS -H "Origin: test.com" -H "Access-Control-Request-Method: GET" http://localhost:8080/
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: *
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Date: Tue, 11 Jun 2019 02:20:35 GMT
Content-Length: 0
The below request doesn't work without the Access-Control-Request-Method header. Our server may have different CORS settings for GET and POST (etc..), and our server can't communicate that to the client. The client must set the Access-Control-Request-Method header so the server knows how to properly respond.
curl -I -X OPTIONS -H "Origin: test.com" http://localhost:8080/
HTTP/1.1 200 OK
Date: Tue, 11 Jun 2019 02:31:12 GMT
Content-Length: 436
Content-Type: text/html; charset=utf-8