¿Cuál es el propósito de MarkDownSharp cuando se usa con PageDown?

Question

Los sitios de StackExchange usan la sintaxis MarkDown para escribir preguntas y respuestas. Esto se crea utilizando PageDown en el lado del cliente y MarkDownSharp y Jeff's HTML sanitizer en el lado del servidor. Estoy pensando en construir algo muy similar yo mismo.

Entiendo por qué necesito desinfectar el HTML en el lado del servidor. ¿Pero cuál es el propósito de MarkDownSharp? ¿Por qué no haría la traducción de MarkDown a HTML con PageDown en el lado del cliente y la enviaría al servidor?

Answer 1

Las razones más importantes:

1. Queremos la más básica (en el sentido de "fundamental") la funcionalidad de los sitios Pila de cambio, preguntar y responder, a trabajar sin JavaScript . Las cosas más avanzadas como votar, marcar, detalles de UI, textos de ayuda, favoritos, bandeja de entrada global y otras cosas que no requieren JavaScript, y eso está bien. Pero lo único que los sitios no pueden vivir sin – Q & A – no debería tener ese requisito, para mantener la fricción lo más baja posible.

   Por supuesto, cuando no tiene JavaScript como requisito, no puede exigir que el cliente presente el Margen.

2. Solo almacenamos la versión HTML representada de la versión más reciente de una publicación. Para revisiones pasadas, solo almacenamos la fuente de reducción. Almacenar ambas versiones para cada edición que se realice sería una gran pérdida de espacio, ya que las versiones antiguas casi nunca se necesitan. Pero a veces se necesitan, p. en el historial de revisión. Entonces, para eso, tenemos que renderizar en el lado del servidor de todos modos.

3. Incluso si vuelve a desinfectar en el lado del servidor, permitir que el cliente haga el renderizado obviamente elimina la confianza que puede tener en la versión renderizada que realmente se realiza a partir del Markdown. Imagine la siguiente:

   I, un spammer mal, publicar la siguiente respuesta:

   As you can sea on [this awesome site][1], 
   
   ... (long text on thread-safe usage of the turtle in LOGO) ... 
   
   Hope that helps! 
   
   [1]: http://almost-real-rolex-watches.biz 
   

   Pero envío una versión procesada en la que el enlace en realidad va a un sitio relevante sobre las complejidades de la concurrencia de tortuga. Dado que el servidor espera tanto el origen de Markdown como el HTML renderizado de mí, confía en que el uno fue hecho del otro.

   A lo largo se encuentra Sean Sceat, reconocido usuario de Stack Overflow con una reputación de 120k solo en la etiqueta del logotipo. Él ve que el enlace realmente va a una página relevante, le gusta la respuesta, lo sube, publica una "Gran respuesta, ¡el sitio al que se vincula tiene toneladas de contenido útil!" comente, y mientras lo hace, arregla el error tipográfico "mar" -> "ver" (que el spammer hizo deliberadamente).

   Pero el Markdown que estaba en el editor después de hacer clic en "editar" hizo que no ya no contenga el enlace correspondiente; contenía el enlace de Rolex. Y por lo tanto, – sin el conocimiento de Sean –, no solo corrigió el error tipográfico, sino que también cambió el enlace para ir al sitio del spammer.

   Ahora tiene una publicación en la que la última edición proviene de un usuario de confianza que respalda la respuesta, pero con un vínculo que preferiría que no hagamos clic en las personas.

   Y el historial de revisiones (consulte el punto 2.), ni siquiera mostrar que el enlace fue cambiado.

Cabe señalar que la versión original del editor de JavaScript WMD en realidad tenía la funcionalidad que describe; puede configurarlo para enviar el HTML renderizado al servidor. Finalmente, eliminamos esa funcionalidad cuando publicamos nuestra versión refactorizada con el nombre "PageDown", ya que nunca la habíamos usado, mantenido y, sinceramente, no sabemos si realmente funcionó.