I am fairly new to using uwsgi, nginx with modsecurity and pagespeed, and django. When I comment out the lines:
ModSecurityEnabled on;
ModSecurityConfig modsec_includes.conf;
in my mysite_nginx.conf I am able to log into the django admin account as expected, but when I enable them, I get
my.server.ip.address didn’t send any data.
ERR_EMPTY_RESPONSE
in my browser when I try to log in. Looking in my nginx error log shows no modsecurity errors. The error it is showing is:
2017/01/26 12:08:13 [alert] 3521#0: worker process 8640 exited on signal 11
Since everything seems to be working fine when modsecurity is off, presumably the problem is arising here.
Compile ModSecurity Branch v3/master (necessary because you need the common core
libmodsecurity)
Compile ModSecurity-nginx connector
Compile nginx with add-module ModSecurity-nginx
Clone and configure OWASP ruleset and config to Nginx
This would work
https://www.howtoforge.com/tutorial/nginx-with-libmodsecurity-and-owasp-modsecurity-core-rule-set-on-ubuntu-1604/
Related
I have a baffling issue with cookie handling in a Blazor server app (.NET Core 6) using openid (Keycloak). Actually, more than a couple which are may or may not linked. It’s a typical (?) reverse proxy architecture:
A central nginx receives queries for services like Jenkins, JypyterHub, SonarQube, Discourse etc. These are mapped through aliases in internal IPs where the nginx can access them. This nginx intercepts URL like: https://hub.domain.eu
A reverse proxy which resolves to https://dsc.domain.eu. This forwards request to a Blazor app running in Kestrel in port 5001. Both Kestrel and nginx under SSL – required to get the websockets working.
Some required background: the Blazor app is essentially a ‘hub’ where its various razor pages ‘host’ in iframe-like the above mentioned services. How it works: When the user asks for the root path (https://hub.domain.eu) it opens the root page of the Blazor app (/).
The nav menu contains the links to razor pages which contain the iframes for the abovementioned services. For example:
The relative path is intercepted by the ‘central’ nginx which loads Jenkins. Everything is under the same Keycloak OpenID server. Note that everything works fine without the Blazor app.
Scenarios that cause the same problem
Assume the user logins in my app using the login page of Keycloak (NOT the REST API) through redirection. Then proceeds to link and he is indeed logged in as well. The controls in the App change accordingly to indicate that the user is indeed authenticated. If you close the tab and open a new one, the Blazor app will act as if it’s not logged in while the other services (e.g Jenkins) will show the logged in user from before. When you press the Login link, you’ll be greeted with a 502 nginx error. If you clean the cookies from browser (or in private / stealth mode) everything works again. Or of you just log off e.g. from Jenkins.
Assume that the user is now in a service such as Jenkins, SonarQube, etc. if you press F5 now you have two problems: you get a 404 Error but only on SOME services such as Sonarcube but not in others. This is a side problem for another post. The thing is that Blazor app appears not logged in again by pressing Back / Refresh
The critical part of Program.cs looks like the following:
This class handles the login / logoff:
Side notes:
SaveTokens = false still causes large header errors and results in empty token (shown in the above code with the Warning: Token received was null). I’m still able to obtain user details though from httpContext.
No errors show up in the reverse proxy error.log and in Kestrel (all deployed in Linux)
MOST important: if I copy-paste the failed login link (the one that produced the 502 error) to a "clean" browser, it works fine.
There are lots of properties affecting the OpenID connect, it could also be an nginx issue but I’ve run out of ideas the last five days. The nginx config has been accommodated for large headers and websockets.
Any clues as to where I should at least focus my research to track the error??
The 502 error shows an error at NGINX's side. The reverse proxy had proper configuration but as it turned out, not the front one. Once we set the header size to suggested size, everything played out.
I am getting the following 500 server error when I deploy my Django web application to google app engine:
Error server error the server encountered an error and could not complete your request please try again in 30 seconds
Simply refreshing the page solves this issue and renders the page. However, this isn't ideal and I want the page to load correctly the first time tried. This error does not occur on my localhost, it only occurs on the deployed site and typically during form submissions and rendering detail pages.
I've researched the HTTP status codes in Django extensively from their documentation. It does not matter if the app is set in DEBUG mode or not. The same error appears. This is happening for both GET and POST requests. I have also tried to use a try-except block to retry the request multiple times before accepting failure.
My configuration:
Django: 3.2.9
Browser: Chrome 98.0.4758.80
Simply needed to upgrade my google app engine tier to a more professional level. Nothing was wrong, I just outgrew my tier and it just needed more computing power.
Dear StackOverflow community, your help would be greatly appreciated.
I have zero experience with IIS. Unfortunately, a Windows Server 2012 with IIS 8.5 is all I can get for the current project. I followed this post by Matt Woodward to get my Django app running on IIS. I serve static files by means of an application that references the static folder. The app looks the way it is supposed to look and all GET requests are processed properly. However, the response to all POST requests (on localhost and remotely) is Status 500 Server Error. If I run my Django app with the runserver command, the POST requests are processed properly.
POST is NOT blocked in IIS Request Filtering -> HTTP Verbs. POST requests are sent to URLs like http:/site_title/update_plan/, not to html. The StackOverflow posts found here and here were not helpful.
I suspect the problem is in the IIS settings, but maybe some special Django settings are required and I am missing it. Any ideas on what can be done to fix the problem would be of great help. Thanks!
I have a Django app running on a gunicorn server with an
nginx up front.
I need to diagnose a production failure with an HTTP 500 outcome,
but the error log files do not contain the information I would expect.
Thusly:
gunicorn has setting errorlog = "/somepath/gunicorn-errors.log"
nginx has setting error_log /somepath/nginx-errors.log;
My app has an InternalErrorView the dispatch of which does an
unconditional raise Exception("Just for testing.")
That view is mapped to URL /fail_now
I have not modified handler500
When I run my app with DEBUG=True and have my browser request
/fail_now, I see the usual Django error screen alright, including
the "Just for testing." message. Fine.
When I run my app with DEBUG=False, I get a response that consists
merely of <h1>Server Error (500)</h1>, as expected. Fine.
However, when I look into gunicorn-errors.log, there is no entry
for this HTTP 500 event at all. Why? How can I get it?
I would like to get a traceback.
Likewise in nginx-errors.log: No trace of a 500 or the /fail_now URL.
Why?
Bonus question:
When I compare this to my original production problem, I am getting
a different response there: a 9-line document with
<h1><p>Internal Server Error</p></h1> as the central message.
Why?
Bonus question 2:
When I copy my database contents to my staging server (which is identical
in configuration to the production server) and set
DEBUG=True in Django there, /fail_now works as expected, but my original
problem still shows up as <h1><p>Internal Server Error</p></h1>.
WTF?
OK, it took long, but I found it all out:
The <h1>Server Error (500)</h1> response comes from Django's
django.views.defaults.server_error (if no 500.html template exists).
The <h1><p>Internal Server Error</p></h1> from the bonus question
comes from gunicorn's gunicorn.workers.base.handle_error.
nginx logs the 500 error in the access log file, not the error log file;
presumably because it was not nginx itself that failed.
For /fail_now, gunicorn will also log the problem in the access log,
not the error log; again presumably because gunicorn as such has
not failed, only the application has.
My original problem did actually appear in the gunicorn error log,
but I had never searched for it there, because I had
introduced the log file only freshly (I had relied on Docker logs
output before, which is pretty confusing) and assumed it would be
better to use the very explicit InternalErrorView for initial
debugging. (This was an idea that was wrong in an interesting way.)
However, my actual programming error involved sending a response
with a Content-Disposition header (generated in Django code) like this:
attachment; filename="dag-wönnegården.pdf".
The special characters are apparently capable of making
gunicorn stumble when it processes this response.
Writing the question helped me considerably with diagnosing this situation.
Now if this response helps somebody else,
the StackOverflow magic has worked once again.
may be server response 500 is logged in access_log not in errorlog
in nginx default file
access_log /var/log/nginx/example.log;
i think <h1><p>Internal Server Error</p></h1> is generated by nginx in production `
in debug=False
raise exception is treated as error or http500,so unless you changed the view for handler500,default 500 error page will be displayed
debug =true
raise exception is displayed in fancy djnago's debug page
On production, I've been trying to add the djangosecure.middleware.SecurityMiddleware (from http://pypi.python.org/pypi/django-secure)to my settings, but haven't had any luck making it work.
When I run:
./manage.py checksecure
Everything passes perfectly fine. But I'm unable to load the site up. It gives me the following error:
The webpage has resulted in too many redirects. Clearing your cookies for this site or
allowing third-party cookies may fix the problem. If not, it is possibly a server
configuration issue and not a problem with your computer.
Locally, when I use the production settings I receive a page error with:
Unable to make a secure connection to the server. This may be a problem with the server,
or it may be requiring a client authentication certificate that you don't have.
My terminal then gets filled with strange errors that I can't decipher:
[12/Jan/2013 14:15:25] code 400, message Bad HTTP/0.9 request type
('\x16\x03\x01\x00\x98\x01\x00\x00\x94\x03\x02P\xf1\xc4]\x97e\xdd\xdc\xa9\xeb\x0e\xfc\xbb\xfa3 ')
[12/Jan/2013 14:15:25] "??P??]?e?ܩ????3 Ʀ?-?:?.E:?o?FH?" 400 -
[12/Jan/2013 14:15:25] code 400, message Bad request syntax ('\x16\x03\x01\x00\x98\x01\x00\x00\x94\x03\x02P\xf1\xc4]M\xeeA50\xfc\x15%\xc1\xa4\x02\xec\xf0\x1fO')
[12/Jan/2013 14:15:25] "??P??]M?A50?%????O" 400 -
[12/Jan/2013 14:15:25] code 400, message Bad request syntax ('\x16\x03\x01\x00\x98\x01\x00\x00\x94\x03\x01P\xf1\xc4]\x8eg\xbey\x155\xafiP5\x85r\xb4|\x8c\x
Any advice?
Infinite-redirects means you have set SECURE_SSL_REDIRECT to True, but in production your site runs behind an SSL-stripping proxy server, so Django can't tell that the request is already in fact SSL, so it continually tries to redirect to SSL. As noted in the linked docs, you need to figure out what header your proxy sets to indicate an externally-SSL request, and set the SECURE_PROXY_SSL_HEADER setting accordingly.
Using the production settings locally will not work because Django's development server does not support SSL. The strange terminal output is your browser trying to make an SSL handshake with a server that doesn't understand SSL.