Hi all,
I have setup setup dhis2 using docker an the dhis2 cli and seeds and runs successfully on 8080. I would like to host on https however. I tried a couple of the nginx examples in the docs and the forums but always get redirects to http. Is there anyway to do this using the cli created cluster as is or is there some modification that needs to be completed. Below was my last nginx config for a reverse proxy that sat out front.
events {}
http {
gzip on; # Enables compression, incl Web API content-types
gzip_types
“application/json;charset=utf-8” application/json
“application/javascript;charset=utf-8” application/javascript text/javascript
“application/xml;charset=utf-8” application/xml text/xml
“text/css;charset=utf-8” text/css
“text/plain;charset=utf-8” text/plain;
HTTP server - rewrite to force use of SSL
#absolute_redirect off;
server {
absolute_redirect off;
listen 80;
server_name _;
return 301 https://$host$request_uri;
}
HTTPS server
server {
absolute_redirect off;
listen 443 ssl;
client_max_body_size 10M;
ssl_certificate /example.crt;
ssl_certificate_key /example.key;
# Proxy pass to servlet container
location / {
proxy_pass http://localhost:8080/;
#proxy_redirect off;
#proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; # https;
proxy_buffer_size 128k;
proxy_buffers 8 128k;
proxy_busy_buffers_size 256k;
proxy_cookie_path ~*^/(.*) "/$1; SameSite=Lax";
}
}
}
Thanks!
To configure DHIS2 to use HTTPS with an Nginx reverse proxy, you can modify your Nginx configuration file as follows:
events {}
http {
gzip on; # Enables compression, incl Web API content-types
gzip_types
“application/json;charset=utf-8” application/json
“application/javascript;charset=utf-8” application/javascript text/javascript
“application/xml;charset=utf-8” application/xml text/xml
“text/css;charset=utf-8” text/css
“text/plain;charset=utf-8” text/plain;
# HTTP server - rewrite to force use of SSL
server {
listen 80;
server_name _;
return 301 https://$host$request_uri;
}
# HTTPS server
server {
listen 443 ssl;
client_max_body_size 10M;
ssl_certificate /example.crt;
ssl_certificate_key /example.key;
# Proxy pass to servlet container
location / {
proxy_pass http://localhost:8080/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme; # Pass the correct protocol
proxy_buffer_size 128k;
proxy_buffers 8 128k;
proxy_busy_buffers_size 256k;
proxy_cookie_path ~*^/(.*) "/$1; SameSite=Lax";
}
}
}
Make sure to replace /example.crt and /example.key with the actual paths to your SSL certificate and key files.
After modifying the Nginx configuration, restart the Nginx service to apply the changes. This configuration will redirect HTTP requests to HTTPS and proxy requests to the DHIS2 instance running on localhost:8080.
1 Like
Thanks moses! Generally i’d say this works but I see some failures. I see in a couple of instances it’s making calls to localhost. For example, https://localhost/api/39/legendSets/fqs276KXCXi?fields=%3Aall%2CattributeValues[%3Aall%2Cattribute[id%2Cname%2CdisplayName]]
Screengrab below if it comes through. Any thoughts here?
1 Like
I saw some docs on setting the cors, given the above error thought i would give that a try but doesn’t seem to save my changes. Seems like i’m getting this error. Interesting as well is my load balancer is returning unhealthy with 400 errors even thought is kind of works.
request failed with status 403
Request: POST …/api/39/configuration/corsWhitelist
(anonymous) @ Api.js:409
Promis
- Lets start with CORS error
A CORS (Cross-Origin Resource Sharing) error occurs when a web page or an application running in a web browser tries to access resources from a different origin or domain. This error is a security mechanism implemented by web browsers to prevent cross-site scripting attacks.
When a browser sends a request to a different domain, it includes an “Origin” header that specifies the domain from which the request originated. The server then checks if the requested resource allows requests from that particular domain. If the server determines that the request violates the same-origin policy, it returns a CORS error.
CORS errors commonly occur in scenarios such as:
- JavaScript requests: When making XMLHttpRequest or Fetch API requests from JavaScript to a different domain.
- API access: When accessing a web API from a different domain.
- Cross-domain AJAX: When attempting to perform AJAX requests to a different domain.
To resolve CORS errors, you can take one or more of the following approaches:
-
Server-side configuration: Configure the server hosting the requested resource to include the appropriate CORS headers in the response. The server needs to respond with the “Access-Control-Allow-Origin” header, which specifies the domains allowed to access the resource. Additionally, other headers like “Access-Control-Allow-Methods” and “Access-Control-Allow-Headers” can be used to define allowed HTTP methods and headers.
-
Proxy server: Set up a proxy server that acts as an intermediary between the client and the server. The client makes requests to the proxy server, which then forwards the request to the target server. Since the proxy server resides in the same domain as the client, it bypasses the CORS restrictions. In our case its NGINX configuration. we need to revisit that.
-
JSONP (JSON with Padding): If you have control over the server-side code, you can modify the server to support JSONP. JSONP is a technique that involves wrapping the response in a JavaScript function call. By using a tag to load the data, you can bypass the CORS restrictions. However, JSONP has security implications and is not recommended unless necessary.
-
CORS browser extension: Use a browser extension that allows you to disable or modify CORS restrictions during development and testing. These extensions are helpful when you’re working locally or need to access resources temporarily for debugging purposes. However, remember to enable the CORS restrictions again before deploying your application to production.
It’s worth noting that CORS errors occur for security reasons, and bypassing them should be done with caution. Always ensure that you understand the potential risks associated with cross-origin requests and implement appropriate security measures.
- Request failed with status 403
A 403 status code indicates that the server understood the request but refuses to fulfill it due to authorization or permissions issues. The server is essentially saying that the requested resource is forbidden and access is not allowed.
There are several possible reasons for receiving a 403 error:
-
Insufficient permissions: The user or client making the request does not have the necessary permissions to access the requested resource. This can occur if you are trying to access a restricted file or directory that requires authentication or specific access rights.
-
Authentication failure: The server requires authentication, but the provided credentials (e.g., username and password) are either missing, incorrect, or expired. In this case, you need to ensure that you provide valid authentication credentials to access the resource.
-
IP blocking or blacklisting: The server may have blocked your IP address or placed it on a blacklist, preventing access to the requested resource. This can happen if the server detects suspicious activity or if your IP address has been flagged for violating server policies.
-
Rate limiting: The server may be enforcing rate limits to restrict the number of requests from a particular client or IP address within a certain time frame. If you exceed the allowed limit, the server may respond with a 403 error until the rate limit resets.
-
Incorrect configuration: There might be misconfigured permissions or access control rules on the server side that are causing the 403 error. Double-check the server configuration to ensure that it is properly set up to allow access to the requested resource.
To troubleshoot and resolve a 403 error, you can try the following steps:
-
Double-check your credentials: If authentication is required, make sure you are providing the correct credentials (username and password) or any required authentication tokens.
-
Verify permissions: Ensure that you have the necessary permissions to access the resource. Check with the server administrator or review the documentation to understand the required access level.
-
Check for IP blocking: If you suspect your IP address may be blocked, try accessing the resource from a different network or contact the server administrator to investigate and potentially remove the block.
-
Review server logs: Examine the server logs or error logs for more detailed information about the 403 error. The logs may provide insights into the specific reason for the access denial.
-
Contact the server administrator: If you’ve tried the above steps and are still encountering the 403 error, it may be best to reach out to the administrator or support team responsible for the server or website. They can provide further assistance and help resolve the issue.
It’s important to respect server permissions and access restrictions. Attempting to bypass a 403 error without proper authorization can be a violation of the server’s policies and potentially illegal.
This still points to the NGINX configuration and how it was configured. Are you able to share your proxy nginx configuration file we see and detect where the misconfiguration is coming from?
hi @moses_mwale , this is the configuration i have: – as a side note I am using the admin/district user that is created with the sierre leone seed db. That user looks to be in the Administrator group but do you think i need to add some permission there? I noticed the same 403 testing the cors update on one of the demo servers (DHIS 2 Demo - Sierra Leone), but i see lots of beautiful data in this server 
Mines not really showing much at the moment.
events {}
http {
gzip on; # Enables compression, incl Web API content-types
gzip_types
“application/json;charset=utf-8” application/json
“application/javascript;charset=utf-8” application/javascript text/javascript
“application/xml;charset=utf-8” application/xml text/xml
“text/css;charset=utf-8” text/css
“text/plain;charset=utf-8” text/plain;
HTTP server - rewrite to force use of SSL
server {
listen 80;
server_name _;
return 301 https://$host$request_uri;
}
HTTPS server
server {
listen 443 ssl;
client_max_body_size 10M;
ssl_certificate /etc/ssl/localhost.crt;
ssl_certificate_key /etc/ssl/localhost.key;
# Proxy pass to servlet container
location / {
proxy_pass http://localhost:8080/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme; # Pass the correct protocol
proxy_buffer_size 128k;
proxy_buffers 8 128k;
proxy_busy_buffers_size 256k;
proxy_cookie_path ~*^/(.*) "/$1; SameSite=Lax";
}
}
}
