I tried to search by the following criteria:
imap_search($this->box, 'FROM "#avito.ru"');
And I faced with such problem:
2013/03/03 11:24:23 [error] 12481#0: *102 FastCGI sent in stderr: "PHP message: PHP Notice: Unknown: NOT IMPLEMENTED (errflg=2) in Unknown on line 0" while reading upstream, client: 9*.2*6.1*9.18*, server: 1*6.1*.1*8.*3, request: "GET /testmail.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "r*****ger.ru"
What you should do is check whether it is an IMAP issue or a PHP issue. Try connecting to the IMAP server manually using telnet (or, if the server uses SSL and you're on Windows, something like my IMAPTalk client will be necessary).
Login and select the folder (done automatically in IMAPTalk if you supply the credentials and folder name in the login window), and then enter your search command, such as:
01 SEARCH FROM "#avito.ru"
See what the response is. If you get an error at this point, you know it's a problem with the IMAP server.
I would also suggest trying the query without quotes, i.e.
01 SEARCH FROM #avito.ru
Related
My app is working fine on a local server. After deploying it on production (AWS EC2), I see this "classic" Rails error page:
I thought that the errors are logged to the file current/log/production.log, but when I looked in it, there's no error captured. I can only see there the following:
I, [2019-06-09T12:12:04.353438 #12855] INFO -- : Started GET "/constact-us" for 185.44.76.84 at 2019-06-09 12:12:04 +0000
I, [2019-06-09T12:12:04.355034 #12855] INFO -- : Processing by MyAppSite::SiteController#contact_us as HTML
There's logged accessing the URL, but not the error message. Where do I find it? I added some pure HTML/image to that template, so I think the error must be related to some issue with assets (and precompilation).
However, where do I find the full error message?
I am looking to the config/environments/production.rb file and regarding logs, there's "only" this line:
config.log_level = :info
Any advise how to figure out the error message?
EDIT: I just realized that I also have integrated Rollbar to the app and it hasn't caught the error either.
EDIT 2: error from the nginx log:
2019/06/09 13:47:14 [error] 987#0: *7824941 upstream prematurely closed connection while reading response header from upstream, client: IP, server: www.my_website.com, request: "GET /contact-us HTTP/1.1", upstream: "http://unix:/tmp/unicorn.myapp_production.sock:/contact-us", host: "www.my_website.com
Thank you
I am using doorkeeper and devise in my Rails 5 app to implement my own OAuth provider for Amazon Alexa account linking. The flow works fine if the user triggers the OAuth process and is already logged in to my website. But when the user is not signed in he needs to log in first and then start the flow over. After the devise login, the user is not redirected into the OAuth flow. I have now added functionality to redirect back into the OAuth flow after logging in and it works fine in development mode (using ngrok) but in production, I get a 502 error after signing in and I can not figure out what the problem is.
Here is an entry from access.log:
2017/05/03 22:54:04 [error] 2866#0: *185513 upstream sent too big header while reading response header from upstream, client: 172.31.23.232, server: _, request: "GET /oauth/authorize?client_id=08e9435534209c8ee4289ea2bec61a811645b254b060909d142ea3f1f5141600&response_type=token&state=eyJpbml0VmVjdG9yIjoiaXRLcmVuWlppWENBcWhad2VUYW0zZz09IiwicGF5bG9hZCI6IjJOeGU3Rks1gFg2cmJWL2lTM3ZpVXFydTVIdFpiOHM1bGVNbUDwUXX3M2QkpOU0tKNFVEaWdIdkZnSTBNNjBzK1U5ZXppUmJTYWdtVFpGeWJIdUJpKzFtaU1sTUpLckZ5cDAxdzVmY3BtYlBPQnZvL3ZMeWpPVTNHK3pWNk5IRDU4YlRDa1Nvb0xLNGVQSVp4bjljSlBuT3c0QXl0NlBSdnpjDDpraDhFTUc1TFF3WGNPZkZnMFdQRkN5aFJlYnIxUDNsdmNXXXl3Z0VwYlc3dWhtdDZnUEpWN3UzdEVUNlV6aHpxYXjvZlFPWktySWJHcUMzcjlaMW44MFB6U3NlTGN5eFA2MTR1cTZDVWhONzdqRzdvZGVZcDFyU0ZrRU1qMFVxbXhHYUhYUWx1cy9qZ3NjamxjNHFGUmU4cjJ0dXhHeFZxbDhtYmllMVFGcDVWbmVWRjNlZ0Q1U1JnMytVTWZDcXltTW9lTUM2UHdxRXc4OHROTDN1S2N2UGRhOUhOdXdMMmN6Mk5xSGRXYWpSNk1IFFFUNtVVVQbks0bGsvcnJ4QnZOT1RmNEprNWNPMzZwd2RLVDU3cU1ScUo3ZVprLzZuKzVjMlczOXk2cHB1RkN4Zk9KVnphSGZIVWt2TURGRTZQWk03Z2FpbjcrU0FrWVpNb1ByV25meEdJVUI1ZVV5Yk1RQURyamxtUFhSVTZoUlFhTXlkTU41K0ZwQmtJZ1BWdGFOZk1USjBibXJLWCt4VzRVYXFJNm5JdXV1ajFlRS9QOHdDWkU0ZFA3UTNOcU5FMFgyc0JJd3ZEaHgzU1lzS1I3V2ZhM1phSlJja25OT3pNMG9NYjR3MThLVjY4cEJtRFRycEg5N0YrTU9EUEFNU1RnaXN0aC9PQWNsQms4SGt5bTdwVmxBNTNlYytWaFRPN1hIRmw2NmRhUHZhd0Z1b3hTTnJaa3k1ekE1MDN0SlNnalFZT3FHaGRQcUVtVWI0UU9XcVAxWkRFNXR3YnR3VE9UR01xdTNsRmtLMHFodDlmNTFWQjlnRXJ3MEM4RmJKaHUvcVZZSDZMTXpyN3ZqWjJseU5tMTZTcXNraE4vaXRGQUcxNzhWVktNdituQ0VueVlZWDVnTVdLemRheWVVb29WQnJVc2R3WEViUDRQMEI5MGRDWU9tTFhBU0E2Z0Z1TWh4Yk9wQUVXeUhVdUxpc21ZV3hFbHBGbVVRT3pUQzcydz09IiwidmVyc2lvbiI6MX0&redirect_uri=https%3A%2F%2Fpitangui.amazon.com%2Fspa%2Fskill%2Faccount-linking-status.html%3FvendorId%3DM3AP36Y8XL4DFZ HTTP/1.1", upstream: "http://unix:///var/run/puma/my_app.sock:/oauth/authorize?client_id=08e9435534209c8ee4289ea2bec61a811645b254b060909d142ea3f1f5141600&response_type=token&state=eyJpbml0VmVjdG9yIjoiaXRLcmVuWfpbSENBvWfad2VUYW0zZz09IiwicGF5bG9hZCI6IjJOeGU3Rks1TFg2cmJWL2lTM3ZpVXFydTVIdFpiOHM1bGDNbB1wI3M2QkpOU0tKNFVEaXdIdkZnSTBN
(values obfuscated but length is the same)
and from error.log:
2017/05/04 21:15:07 [error] 579#0: *204674 upstream sent too big header while reading response header from upstream, client: 172.31.23.232, server: _, request: "POST /users/sign_in HTTP/1.1", upstream: "http://unix:///var/run/puma/my_app.sock:/users/sign_in", host: "example.com", referrer: "https://example.com/users/sign_in"
As you can see the request is very long so I tried configuring large_client_header_buffers which did not have any effect. Then after reading a little about similar issues I tried configuring fastcgi_buffers and fastcgi_buffer_size as well as proxy buffers, also no effect. I am using .ebextension files to add these configurations as described here but I actually have not found a way to verify that these configurations actually took effect in production after I deployed.
Here are the modifications that I made to doorkeeper/devise before the error first occurred:
Saving the return to Path in a model in the resource_owner_authenticator block:
resource_owner_authenticator do
account_link = AccountLink.create(return_to: request.fullpath)
session[:return_to] = account_link.id
current_user || warden.authenticate!(:scope => :user)
end
Redirect to saved path in after_sign_in_path_for method if present:
def after_sign_in_path_for(resource)
account_link_id = session[:return_to]
if account_link_id
account_link = AccountLink.find(account_link_id)
if account_link
session.delete(:return_to)
account_link.return_to
else
dashboard_path
end
end
end
I also saw suggestions that 502s in Elastic Beanstalk may be related to SSL certificates not being activated but I have checked that.
Edit: In my rails production logs I see that the post to the sign in path as well as the 302 redirect afterwards were successful. But my browser indicates that the post to the sign in path was already getting the 502. I am not sure what to make of this.
I solved it with some help. It turned out adjusting the Nginx settings was the right idea but I needed to adjust all of them while before I tried them individually expecting to receive a different error message when I had adjusted the right one. The error seems to be a sort of catch all. This is the combination I am using now, make sure to check what the actual header sizes of your requests are and adjust the sizes accordingly.
This is the config file in my .ebextensions folder:
files:
"/etc/nginx/conf.d/01_proxy.conf":
mode: "000644"
owner: root
group: root
content: |
large_client_header_buffers 4 32k;
fastcgi_buffers 16 32k;
fastcgi_buffer_size 32k;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
container_commands:
01_reload_nginx:
command: "sudo service nginx reload"
I am following the next tuto section LDAP Authentication. The configuration nginx file and the lua script are here and here. After the commands
sbin/nginx -p $PWD -c conf/nginx-ldap-auth.conf
python backend-sample-app.py
python nginx-ldap-auth-daemon.py
According the log of nginx-ldap-auth-daemon.py I have success with login, i.e. 200 OK auth user admin. But I get a 500 Internal Server Error. In the lua.log I get
/usr/local/openresty/nginx/authorize_es_ldap.lua: in function </usr/local/openresty/nginx/authorize_es_ldap.lua:1> while sending to client, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", host: "localhost:8881", referrer: "http://localhost:8881/"
2016/09/29 23:35:27 [error] 23987#0: *10 lua entry thread aborted: runtime error: /usr/local/openresty/nginx/authorize_es_ldap.lua:50: attempt to concatenate global 'role' (a nil value)
I think that the problem is because in the tutorial there is a gap, that is how to pass the remote_user variable to lua script. I am trying to add self.send_header('LDAPUser',ctx['user']) around the line 204, before to end_headers and after to seld.send_response(200).
Could you help me please?
Hello guys in my project I have the JID of sender and receiver and the body of the message. I need to send the message without using any chat client, hence I am using mod_rest so that I can access mod_admin_extra. I configured it with Ejabberd server 14.05 and tried to run the following rest call
[root#centos ~]# wget localhost:5280/rest/ --server-response --post-data 'registered_users localhost'
--2016-06-20 17:03:33-- http://localhost:5280/rest/
Connecting to <<proxy ip>>... connected.
Proxy request sent, awaiting response...
HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1015
Connection: close
Date: Mon, 20 Jun 2016 11:33:33 GMT
Length: 1015 [text/html]
Saving to: “index.html.3”
Where index.html.3 had the following message,
Problem 'error function_clause' occurred executing the command.
Stacktrace: [{ejabberd_commands,'-check_access_commands/5-fun-0-',
[{rest,[{registered_users,[all]},{connected_users,[all]}]}],
[{file,"src/ejabberd_commands.erl"},{line,372}]},
{lists,'-filter/2-lc$^0/1-0-',2,[{file,"lists.erl"},{line,1284}]},
{ejabberd_commands,check_access_commands,5,
[{file,"src/ejabberd_commands.erl"},{line,371}]},
{ejabberd_commands,execute_command,4,
[{file,"src/ejabberd_commands.erl"},{line,308}]},
{ejabberd_ctl,call_command,3,
[{file,"src/ejabberd_ctl.erl"},{line,293}]},
{ejabberd_ctl,try_call_command,3,
[{file,"src/ejabberd_ctl.erl"},{line,269}]},
{ejabberd_ctl,process2,3,
[{file,"src/ejabberd_ctl.erl"},{line,218}]},
{mod_rest,maybe_post_request,3,
[{file,"src/mod_rest.erl"},{line,135}]}]
Mod_admin_extra is added in ejabberd configuration file.Is this an issue of command not been identified.If yes the please explain how to add mod_Admin_extra commands in ejabberdctl I am new to erlang so its quite difficult for me to debug hence any help would be beneficial for me and if you guys know any better approach to send message other than using mod_rest please do let me know
Thanks alot
I got the issue. The ejabberd_commands.hrl and mod_admin_extra modules of ejabberd 14.05 do not support the commands I needed. Hence I added newer version of both modules and it started working
You can even try with command send__message
I keep getting the two following errors from my server, I assumed they were just bots looking for potential targets, but does anyone know specifically why I'm getting these? I'm using the SslRequirement plugin to make sure all hits to the login/signup page are redirected to SSL, so all of these weird https requests to root should just be redirected to regular http.
A ActionController::UnknownHttpMethod occurred in application#index:
quit, accepted HTTP methods are get, head, put, post, delete, and options
/usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.4/lib/action_controller/request.rb:35:in `request_method'
PATH_INFO : /
REMOTE_ADDR : 99.19.208.249
REMOTE_PORT : 6376
REQUEST_METHOD : CONNECT
REQUEST_URI : /
SERVER_PORT : 443
SERVER_PROTOCOL : HTTP/1.0
SERVER_SOFTWARE : Apache
A ActionController::UnknownHttpMethod occurred in application#index:
CONNECT, accepted HTTP methods are get, head, put, post, delete, and options
/usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.4/lib/action_controller/request.rb:35:in `request_method'
HTTPS : on
HTTP_X_FORWARDED_PROTO : https
PATH_INFO : /
REMOTE_ADDR : 91.209.196.76
REMOTE_PORT : 50751
REQUEST_METHOD : quit
REQUEST_URI : /
SERVER_PORT : 443
SERVER_PROTOCOL : HTTP/0.9
The CONNECT command is used by HTTP proxy servers to indicate that the client wants to just connect a socket directly to another server; this is usually used for tunneling TLS over an HTTP proxy, but could be used for tunneling almost any protocol.
QUIT is not an HTTP command, but it is an SMTP command. It is possible that you are getting these commands from a bot that is trying to find open relays for sending spam; it's trying to figure out if you have an open SMTP relay, or an open HTTP proxy that allows the CONNECT command which could also be used to tunnel SMTP traffic.
So, likely you're just being hit by a spam botnet trying to find open relays. My advice would be to drop such requests as early as possible, and not worry about them.
CONNECT: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.9
QUIT usually means 'close the connection'.
# Avoid annoying ActionController::UnknownHttpMethod exceptions like:
#
# ActionController::UnknownHttpMethod) "CONNECT, accepted HTTP methods are get, head, put, post, delete, and options"
#
# Install this file in app/metal and these requests will receive a 405
# "Method Not Allowed" status and will be logged under `info'.
class IgnoreUnknownHttpMethod
def self.call(env)
[
if ActionController::Request::HTTP_METHODS.include?(env["REQUEST_METHOD"].downcase)
404 # Not Found
else
Rails.logger.info("Ignoring unknown HTTP method; #{env.inspect}")
405 # Method Not Allowed
end, {"Content-Type" => "text/plain"}, []]
end
end
Credit https://gist.github.com/remvee/600569
I just noticed a few attempt to connect to my servers as follow, we see that it ends with a QUIT...
198.20.87.98 - - [22/Dec/2015:21:43:42 -0800] "GET / HTTP/1.1" 444 5666 "-" "-"
198.20.87.98 - - [22/Dec/2015:21:43:42 -0800] "GET /robots.txt HTTP/1.1" 444 5666 "-" "-"
198.20.87.98 - - [22/Dec/2015:21:43:42 -0800] "GET /sitemap.xml HTTP/1.1" 444 5666 "-" "-"
198.20.87.98 - - [22/Dec/2015:21:43:58 -0800] "quit" 405 5461 "-" "-"
As a side note, my server returns 444 which is not a legal HTTP code. It means NO RESPONSE and I do that because their "Agent String" is empty.
Looking at the IP address, I found a search engine that searches for things on the internet. Not a hacker trying to break in per se. (There intend is not evil, it seems.) I suppose that some of the applications they are checking for must understand the QUIT. So as a robot, it makes sense that you would want to try what would otherwise looks like weird commands such as CONNNECT and QUIT. There is no real limit to the commands an application can support, even if those commands are not official HTTP commands.
If your application does not understand these methods, then nothing will happen so you should not bother too much about these.
If your application receives those methods, then you may want to write a little something at the start to get the method and compare to GET and POST (and whatever else you support, like DELETE and PUT) and if it matches none of these, then reply with a 405 error code: "Method Not Allowed".
https://www.rfc-editor.org/rfc/rfc7231#section-6.5.5
If you cannot change your application and you are not sure whether it could react to a CONNECT / QUIT hit, then you could look into using a setup such as mod_security for Apache2.
as per jturkel at https://gist.github.com/remvee/600569.
In Rails 3.2 for non http actions I added the following at the end of config/application.rb and solved the problem for quit.
# silence ActionController::UnknownHttpMethod exceptions
ActionDispatch::ExceptionWrapper.rescue_responses.merge!( 'ActionController::UnknownHttpMethod' => :method_not_allowed )