so I'm working on a website project with the goal of writing my own blog posts with markdown syntax.
Perché? Cosa c'è di sbagliato con le soluzioni esistenti?
I plan on storing this in my MSSQL database. (related question) Do you agree that this is the best way of handling it?
Non sono d'accordo che questo sia il modo migliore . È uno dei modi per farlo. Per il mio blog , ho usato MongoDB. Non è né una scelta migliore, né una scelta peggiore.
I'd like to download images references in the markdown onto my server to guarantee the availability once used in a post. I plan on storing these on the servers filesystem with an updated reference in the markdown (related question). This requires me to parse/extract the markdown to find the relevant usages, how would you do this? Would you even bother to do this?
Ci sono molti problemi con questo:
-
Non dovresti modificare in modo nascosto il post originale. Puoi usare la tecnica usata nello Stack Exchange dove l'utente può caricare le immagini, ma modificare il Markdown originale senza il consenso dell'utente è rischioso (puoi involontariamente rovinare il post) e ingannare (come utente, vorrei essere molto sorpreso di vedere tutti i miei collegamenti sostituiti da qualcos'altro sotto il cofano).
-
Apri il tuo sito a potenziali attacchi (se non sei l'unico che può pubblicare articoli). Cosa succede se l'immagine non è un'immagine, ma uno script dannoso che salverà sul tuo server? O se l'immagine è larga 5 GB, rendendo estremamente semplice l'esecuzione di un attacco DOS?
-
È possibile utilizzare il sito per attaccare altri siti (se non si è l'unico che può pubblicare articoli). Immagina uno script che pubblichi, ancora e ancora, un messaggio contenente qualche migliaio di link alle immagini da un determinato server. Tu sarà ora quello che esegue un attacco DOS sul server che ospita le immagini.
-
Potrebbero esserci anche problemi legali. Se un'immagine è protetta da copyright e la si clona sul server, è possibile che si tratti di un grosso problema.
-
Le immagini sono la cosa che fa un uso pesante della larghezza di banda. Perché dovresti pagare una larghezza di banda extra per questo, invece di lasciare che altri server lo facciano?
A potential benefit I see with this is the ability to log/track the access of those images
Perché ti interesserebbe questo? Hai già le statistiche per un determinato articolo. Google Analytics ti darà ancora più informazioni sugli utenti.
Would you process/convert the markdown every time a user opens the page?
Lo stesso Markdown produce sempre lo stesso HTML. Pertanto, non è necessario generarlo più e più volte ogni volta che qualcuno visita la pagina.
Memorizza HTML fianco a fianco. Aggiornalo quando Markdown è modificato.
Se, per qualche motivo, è più facile generare codice HTML quando viene visualizzata una pagina, assicurati almeno di fare affidamento sul caching aggressivo.
A proposito, se non sei l'unico che può pubblicare articoli, lasciare che la generazione di HTML si verifichi durante il caricamento della pagina rende facile eseguire un attacco DOS. Un Markdown dannoso (cioè creato appositamente per la conversione in HTML richiederebbe molto tempo) potrebbe essere iniettato, e quindi l'attaccante chiamerebbe semplicemente in loop la pagina che mostra l'articolo.
I thought about writing my own markdown processor to get more flexibility, I'm not sure how smart this is.
Non intelligente. Markdown è relativamente complesso da analizzare e tu introdurrà bug. Questi bug potrebbero quindi essere sfruttati per hackerare il tuo server.
Le implementazioni esistenti delle conversioni da Markdown a HTML sono relativamente stabili e molte di esse sono state esaminate da molte persone. A meno che il tuo progetto non sia specifico per creare un convertitore concorrente, usa solo quelli esistenti.
Also, how would one apply custom styling to it (e.g. for code snippets?) and so forth.
Alcuni convertitori Markdown in HTML possono essere personalizzati per abilitare l'uso di tag personalizzati.
Inoltre, non dimenticare che gli elementi HTML possono essere inseriti in Markdown.
Are there any potential downsides to having an editor like that?
Uno dei problemi è che avrete due convertitori Markdown to HTML: uno lato server utilizzato per generare l'HTML che verrà mostrato in seguito ai lettori e uno client-side che mostrerà i contenuti al scrittore di un post sul blog. Il mantenimento di entrambi non è particolarmente difficile, ma richiede comunque un lavoro aggiuntivo. Alcune funzionalità disponibili in una versione potrebbero non essere disponibili nell'altra.
Ovviamente è possibile utilizzare un solo convertitore effettuando richieste AJAX sul server ogni volta che l'articolo viene modificato. Tuttavia, devi fare attenzione ad evitare di fare una richiesta per ogni carattere digitato: per articoli lunghi o leggermente esoterici, userà molte risorse e larghezza di banda.