Microsoft Office Protocol Discovery method OPTIONS


#1

Muy buenas, hasta hace poco el exception notifier nos mandaba correos en
lsoq eu nos informaba que el method OPTIONS no estaba permitido, el cual
personalmente no habia visto hasta entonces. Era algo similar a esto:

A ActionController::NotImplemented occurred in application#index:

Only requests are allowed.
[RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/routing/route_set.rb:389:in
`recognize_path’


Environment:

  • CONTENT_LENGTH : 0
  • HTTP_CONTENT_LENGTH : 0
  • HTTP_USER_AGENT : Microsoft Office Protocol Discovery
  • HTTP_VERSION : HTTP/1.1
  • REQUEST_METHOD : OPTIONS
  • REQUEST_URI : /static/

Tras investigar un poco vimos que era un methodo de Microsoft Office y
encontramos una direccion muy interesante en donde se comentaba como
solucionar el problema, adjunto el link por si a alguien le interesa:

http://rails.learnhub.com/lesson/2318-dealing-with-microsoft-office-protocol-discovery-in-rails

La solucion que propone es bastante sencilla, para todas las direcciones
miro si el metodo es options y si lo es hago un status 200. Lo que hace
que ya no se genere el mail del exception notifier.

Hemos seguido al pie de la letra, los pasos que se explican en el link
anterior, encontrandole a todo el sentido, pero tras subirlo al servidor
el notifier nos esta mandando un sinfin de correos de este tipo:

A ActionController::MethodNotAllowed occurred in application#index:

Only options requests are allowed.
/opt/ruby-enterprise-1.8.6-20081215/lib/ruby/gems/1.8/gems/actionpack-2.1.2/lib/action_controller/routing/recognition_optimisation.rb:65:in
`recognize_path’


Request:


Environment:

  • CONTENT_LENGTH :

  • DOCUMENT_ROOT : /var/www/vhosts/rankia.net/current/public

  • HTTP_ACCEPT : image/gif, image/x-xbitmap, image/jpeg,
    image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel,
    application/vnd.ms-powerpoint, application/msword, /

  • HTTP_ACCEPT_LANGUAGE: es

  • HTTP_REFERER :
    http://images.google.com/images?gbv=2&hl=es&q=desnudas&sa=N&start=40&ndsp=20

  • PATH_INFO :
    /blog/hablandodebolsa/uploaded_images/3007824-md-769154.jpg

  • REQUEST_METHOD : GET

  • REQUEST_URI :
    /blog/hablandodebolsa/uploaded_images/3007824-md-769154.jpg

Lo curioso es que TODOS los correo que nos estan llegando tienen como
origen una oeticion GET a algun tipo de imagen, ya sea jpg, gif, etc. Es
sin duda lo que ams nos sorprende, que falle solo con las imagenes ( y
porsupuesto teniendo encuenta que en ningun momento se diga que solo
esta permitido el method OPTIONS, de hecho lo unico que hacemos es
filtrar las rutas que se acceden con este metodo, pero obligar a que sea
el unico).

Cualquier comentario sea bien recibido, intentamos ahorrarnos unos
cuantos correos y nos esta saliendo el tiro por l culata :(…

Salu2


#2

2009/5/5 Jose vicente Ribera pellicer
removed_email_address@domain.invalid:


miro si el metodo es options y si lo es hago un status 200. Lo que hace
`recognize_path’
Environment:
http://images.google.com/images?gbv=2&hl=es&q=desnudas&sa=N&start=40&ndsp=20
sin duda lo que ams nos sorprende, que falle solo con las imagenes ( y
Posted via http://www.ruby-forum.com/.


Ror-es mailing list
removed_email_address@domain.invalid
http://lists.simplelogica.net/mailman/listinfo/ror-es

¿Qué tienes delante de Rails como servidor web? Lo digo porque con un
par de líneas de ModRewrite en Apache eso estaría solucionado y no
tendrías que “despertar” a Rails para algo tan nimio como enviar una
página en blanco.

PD: El ejemplo que has escogido es muy ejemplar de la fauna de internet
XP


#3

2009/5/5 Jose vicente Ribera pellicer
removed_email_address@domain.invalid

Muy buenas, hasta hace poco el exception notifier nos mandaba correos en
lsoq eu nos informaba que el method OPTIONS no estaba permitido, el cual
personalmente no habia visto hasta entonces. Era algo similar a esto:

La aproximación que usas a mi personalmente no me gusta.
En la documentación del plugin, recomiendan, si es mucha la
modificación,
usar rescue_action_in_public del applications controller.

will render public/500.html and will send the email notification. If you
want
to use different rules for the notification, you will need to implement
your
own rescue_action_in_public method. You can look at the default
implementation
in ExceptionNotifiable for an example of how to go about that.

Si vemos la implementación del ejemplo, creo que la solución es más
fácil y
limpia que la que propone el post al que citas, dandote más control y
sin
sobrecargar la aplicación con comprobaciones que se solucionan
fácilmente
con excepciones.
Con que añadas un when ActionController::NotImplemented, estaría
solucionado.

def rescue_action_in_public(exception)
  case exception
    when *self.class.exceptions_to_treat_as_404
      render_404

    else
      render_500

      deliverer = self.class.exception_data
      data = case deliverer
        when nil then {}
        when Symbol then send(deliverer)
        when Proc then deliverer.call(self)
      end

      ExceptionNotifier.deliver_exception_notification(exception, 

self,
request, data)
end
end
*
*

Yo hubiese tirado por ahí. No se si será la mejor opción, pero me gusta
más
que la opción que propone el post.


Guillermo Álvarez

Sent from Madrid, Comunidad de Madrid


#4

¿Qué tienes delante de Rails como servidor web? Lo digo porque con un
par de líneas de ModRewrite en Apache eso estaría solucionado y no
tendrías que “despertar” a Rails para algo tan nimio como enviar una
página en blanco.

PD: El ejemplo que has escogido es muy ejemplar de la fauna de internet
XP

Usamos Apache asi que mirare lo que comentas del ModRewrite.

Con que añadas un when ActionController::NotImplemented, estaría
solucionado.

El problema que le veo a esto es que este tipo de solucion puede
enmascararme en el futuro otro tipo de errores.

Muchas gracias, voy a buscar informacion sobre el Modrewrite (me queda
bastante por aprender de Apache) y si a una mala no consigo que funcione
estudiare la idea que propone Guillermo.

Saludos


#5

Lo digo porque con un par de líneas de ModRewrite en Apache eso estaría >solucionado

Aunque esto no sea un foro de Apache agradeceria si fuera posible y no
molesta a nadie un poco de ayuda en el tema. Por lo que he podido ver lo
primero que tengo que hacer es ver si el modulo esta activado, esto lo
hago editando el archivo http.conf y descomentando la siguiente linea:

#Load module rewrite_module

Una vez me aseguro que tengo el mod_rewrite instalado creamos un nuevo
archivo de configuracion .htaccess. Aqui es dondeiniciamos el modulo
mod_rewrite y tendria que aparecer algo como esto:

RewriteEngine On #inicio el modulo mod_rewrite
RewriteCond %{REQUEST_METHOD} ^OPTION$ #la condicion es el metodo
OPTIONS
RewriteRule return 200 #quiero que me de devuelva un
erro 200.

Me gustaria saber si seria algo parecido a esto, ya que tocar el Apache
me impone un poco de respeto…

Saludos


#6

2009/5/6 Jose vicente Ribera pellicer
removed_email_address@domain.invalid:

Me gustaria saber si seria algo parecido a esto, ya que tocar el Apache
me impone un poco de respeto…

Saludos

Por que quede también está posible solución completa en la lista:

Crea un archivo blank.txt totalmente vacio en la raíz del server (por
ejemplo con touch blank.txt). Incluye estas líneas en tu .htaccess:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^OPTION$
RewriteRule . /blank.txt [L]

Y voila! debería enviar el contenido en blanco y un HTTP 200 OK como
respuesta.

Suerte.


#7

Finalmente y tras hablarlo con los compañeros hemos decidido optar por
la solucion que proponi Guillermo.
Ha quedado asi:

def rescue_action_in_public(exception)
case exception
when *self.class.exceptions_to_treat_as_404
render_404

    ##########ESTO LO AÑADO AL PLUGIN PARA EVITAR EL METHOD OPTIONS 

DEL OFFICE–>si no implementa un method saco un 200###########
when ActionController::NotImplemented
render_200
#####################################################################################################################
else
render_500
.
.
.

De todas formas, si alguien sabe la forma o conoce alguna referencia
para informarme le estaria muy agradecio pues en un futuro nunca se sabe
que se tendra que usar.

Gracias


#8

2009/5/6 Daniel R. Troitiño removed_email_address@domain.invalid

Por ser respetuosos con el medio ambiente: el 200 OK es incorrecto.
Deberia
devolverse un 501 Not Implemented

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

“The server does not support the functionality required to fulfill the
request. This is the appropriate response when the server does not
recognize
the request method and is not capable of supporting it for any
resource.”


#9

2009/5/6 Fernando C. removed_email_address@domain.invalid

Yo voto por un 405 Method_Not_Allowed, ya que es la respuesta a una
petición con el método OPTIONS.

Pero desde luego, no un 200 OK.

Buen punto. Yo creo que un 405 es el adecuado para un método reconocido,
pero no permitido, vamos “no allowed”. Es decir, el típico post contra
un
recurso que solo acepta gets.

Ya que no se trata de permitir o no permitir, sino de que el servidor
reconozca el método, sigo votando por el 501.

Me encantan las discusiones sobre status http :slight_smile:


#10

Yo voto por un 405 Method_Not_Allowed, ya que es la respuesta a una
petición con el método OPTIONS.

Pero desde luego, no un 200 OK.

s2


#11

Crea un archivo blank.txt totalmente vacio en la raíz del server (por
ejemplo con touch blank.txt). Incluye estas líneas en tu .htaccess:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^OPTION$
RewriteRule . /blank.txt [L]

Y voila! debería enviar el contenido en blanco y un HTTP 200 OK como
respuesta.

Suerte.

Gracias Daniel!!. Por cierto si como han comentado en el hilo en vez de
enviar un HTTP 200 ok quisiera enviar un 405 o un 501 como lo
especificaria??.

Porque el hecho de crear el archivo vacio es para que no devuelva nada y
supongo que el 200 es el que se toma por defecto si no se dice nada
(vamos que todo ha ido bien).

PD. sabeis de algun manual/tutorial que me pueda servir para ponerme las
pilas en este tema. Ayer googleando solo encontre entradas muy
especificas sobre apache, pero nada parecido a un tutorial.

S2


#12

Estais alterando el comportamiento normal de rails, que por defecto
cuando
le hacen un options devuelve un method not allowed.
El problema es que esa operación enviaba mails, y en vez de hacer que no
envíe mails, estáis alterando el correcto comportamiento de rails.

Si no vas a usar el verbo options, en la documentación de apache tienes
la
forma de limitar los verbos que quieres.
http://httpd.apache.org/docs/2.2/mod/core.html#limitexcept

En nginx parece que también se puede, aunque usando rewrite
http://wiki.nginx.org/NginxRewriteMultiCondExample

Pero tanto apache como nginx hace un montón que no los toco.


#13

Guillermo wrote:

Estais alterando el comportamiento normal de rails, que por defecto
cuando
le hacen un options devuelve un method not allowed.
El problema es que esa operación enviaba mails, y en vez de hacer que no
envíe mails, estáis alterando el correcto comportamiento de rails.

Si no vas a usar el verbo options, en la documentación de apache tienes
la
forma de limitar los verbos que quieres.
http://httpd.apache.org/docs/2.2/mod/core.html#limitexcept

En nginx parece que también se puede, aunque usando rewrite
http://wiki.nginx.org/NginxRewriteMultiCondExample

Pero tanto apache como nginx hace un montón que no los toco.

Thanks por la info :wink: