React: Memiliki dukungan Fragmen yang berbahayaSetInnerHTML

Kedua ini!

Mencapai ini saat ini membutuhkan dukungan pihak ketiga melalui lib seperti https://github.com/remarkablemark/html-react-parser yang agak merusak kesederhanaan Fragmen.

Tampaknya tidak tepat bagi saya untuk meletakkan sesuatu seperti ini pada Fragment itu sendiri karena tidak spesifik DOM (misalnya bekerja pada React Native).

Saya pikir pada dasarnya Anda meminta "mandiri" dangerouslySetInnerHTML . Kedengarannya seperti https://github.com/facebook/react/issues/9483 . Mungkin sesuatu seperti ini akan lebih masuk akal bagi saya daripada API saat ini:

import { RawHTML } from 'react-dom';

const content = {
  __dangerousHTML: '<h1>hi</h1>'
};
<RawHTML>{content}</RawHTML>

(Juga terinspirasi oleh https://github.com/facebook/react/issues/2134#issuecomment-67687628)

Saya tidak tahu betapa sulitnya menerapkan sesuatu seperti ini.

@gaearon Pada dasarnya itulah yang dicapai oleh html-react-parser . Namun, tujuan di balik prosedur dangerouslySetInnerHTML={{__html: HTML}} yang sengaja jelek/berulang sebenarnya adalah untuk mengingatkan bahwa ini adalah hal yang berbahaya/retas untuk dilakukan:

Dari dokumen:

Jadi, Anda dapat mengatur HTML langsung dari React, tetapi Anda harus mengetikkan HazardlySetInnerHTML dan meneruskan objek dengan kunci __html, untuk mengingatkan diri Anda bahwa itu berbahaya.

Saya merasa ingin menambahkan ini ke Fragment mempertahankan gagasan bahwa ini "berbahaya" & "retas" seperti yang dimaksudkan semula.

Contoh Anda (dan dengan asosiasi, html-react-parser) dapat digunakan dengan cara yang dapat dengan mudah menyamarkan fakta bahwa itu berbahaya; meninggalkan pengelola kode di masa mendatang tanpa indikasi potensi kerentanan.

@jonnyasmar Silakan lihat diskusi di https://github.com/facebook/react/issues/2134#issuecomment -67687628 tentang ini, saya sengaja menyimpan dangerous di nama properti objek karena itulah bagian yang seharusnya menjadi "tercemar" daripada nama prop.

@gaearon Setelah menyisir masalah Anda, saya masih belum sepenuhnya yakin ini adalah pendekatan terbaik.

Sebagian karena skenario seperti berikut:

Ada banyak lagi yang mengikuti kode. Tolong tetap bersamaku.

Katakanlah kita memiliki dua pengembang, Dev A & Dev B . Mereka berdua bekerja di proyek yang sama. Dev A adalah dev senior yang sangat mengenal kerentanan XSS. Dev B adalah dev junior yang tahu apa itu kerentanan XSS, tetapi belum tentu cukup berpengalaman untuk mengenalinya.

Dev A membuat komponen berikut, _karena mereka tahu apa yang mereka lakukan_:

import { RawHTML } from 'react-dom';

export class InjectHTML extends React.Component{
  props: {
    html: string
  };

  render(){
    const content = {
      __dangerousHTML: this.props.html
    };

    return <RawHTML>{content}</RawHTML>
  }
}

Dev B datang dan menemukan dalam kode sumber komponen kecil yang rapi ini disebut InjectHTML .

Pegang bir saya...

import { InjectHTML } from './components/InjectHTML';

export class CoolComponentWithHTML extends React.Component{
  render(){
    return <InjectHTML html={'I AM BERY BERY SNEAKY SIR'}/>
  }
}

Sekarang, Anda mungkin bertanya pada diri sendiri:

Apa yang mencegah hal ini terjadi dengan pendekatan Fragmen yang disarankan OP?

Sama sekali tidak ada.

Berkat keserbagunaan React yang belum pernah terjadi sebelumnya, kami dapat membuat komponen penyuntikan HTML yang sama dan berbahaya.

Jadi, apa manfaat dari pendekatan Fragmen ini?

Kesederhanaan

Dengan mengizinkan fungsi ini pada komponen Fragment itu sendiri, saya pikir kami menghindari mendorong implementasi yang terlalu KERING seperti yang dibuat oleh Dev A.

Konsistensi

Dengan menggunakan Fragment untuk ini, kami juga menghindari keharusan mengimplementasikan dua komponen berbeda yang menyelesaikan hal yang sama (render tanpa pembungkus). Ini adalah tujuan Fragment . Mengapa menghindari menggunakannya?

Kami juga menghindari perubahan perilaku yang sudah biasa dilakukan para pengembang sekaligus membuat implementasi yang dapat diprediksi untuk pengembang seperti OP yang (seharusnya?) menganggap ini akan berhasil .

Mengenai React Native

Kami dengan anggun menurunkan jika perlu dan dangerouslySetInnerHTML tidak melakukan apa-apa. Saya tidak yakin saya melihat ada masalah dengan itu?

Masa Depan (Beropini)!

Saya pribadi MENCINTAI memiliki Fragment saya miliki sekarang dan saya akan sangat tertarik untuk melihat fungsionalitas keren seperti apa yang dapat kami beli dari permata kecil ini.

key adalah satu-satunya atribut yang dapat diteruskan ke Fragment . Di masa mendatang, kami dapat menambahkan dukungan untuk atribut tambahan, seperti event handler .

Ide event handler pada Fragment 's akan _awesome_ dan saya benar-benar berpikir kita harus mencoba untuk mendorong dengan cara apapun kita dapat membuat Fragment fitur yang lebih kuat dari React. Harus membungkus sesuatu yang tidak perlu mungkin adalah satu-satunya hal yang harus saya lakukan secara teratur di React yang membuat saya ngeri...

Saya katakan mari kita membuat Fragment terkenal!

Bagi mereka yang menemukan masalah ini dan berjuang untuk menemukan solusi, lihat di bawah apa yang kami lakukan sampai reaksi memiliki cara untuk menyuntikkan HTML tanpa pembungkus:

// In our generator code we use:
<cuttlebellesillywrapper key={ ID } dangerouslySetInnerHTML={ { __html: HTML } } />

// and before we write to disk we do
/**
 * Clean react output of any silly wrapping divs
 *
 * <strong i="6">@param</strong>  {string} html - The HTML generated with react
 *
 * <strong i="7">@return</strong> {string}      - The cleaned HTML
 */
export const ParseHTML = ( html ) => {
    if( typeof html === 'string' ) {
        return html
            .replace(/<cuttlebellesillywrapper>/g, '')
            .replace(/<\/cuttlebellesillywrapper>/g, '');
    }
    else {
        return html;
    }
}

CreateFile( pathToFile, ParseHTML( html ) )

Di SSR, menggunakan Fragmen, mungkin membantu menghindari kaleng html yang tidak valid ini:

<div dangerouslySetInnerHTML={{ __html: `<link rel="preload" href="${props.assets.fonts}" as="style" onload="this.onload=null;this.rel='stylesheet';" />` }} />

Pada SSR: onload dihapus, jadi satu-satunya solusi adalah menggunakan dangerouslySetInnerHTML . Namun, Fragment tidak mendukungnya. Jadi sekarang, saya punya div > link , browser tampaknya cukup pintar untuk membuat font memuat async.

Pada dasarnya itulah yang dicapai oleh html-react-parser. Namun, tujuan di balik prosedur yang sengaja jelek/berulang-ulang HazardlySetInnerHTML={{__html: HTML}} sebenarnya adalah untuk mengingatkan bahwa ini adalah hal yang berbahaya/peretasan untuk dilakukan:

Tidak ada peretasan dalam menyuntikkan HTML yang Anda hasilkan dari penurunan harga misalnya. dangerouslySetInnerHTML selalu merupakan nama yang aneh. Alarm bahaya palsu juga merusak keamanan.

Saya mendukung usulan RawHtml – saya bahkan akan mengatakan itu sudah lama tertunda.
Jangan pedulikan proposisi awal untuk memperpanjang React.Fragment juga.

Dev A membuat komponen berikut, karena mereka tahu apa yang mereka lakukan

Saya pikir dalam skenario Anda, Dev A tidak sepenuhnya memahami cara kerja tainting. Jika mereka melakukannya, mereka tidak akan menulis kode seperti

    const content = {
      __dangerousHTML: this.props.html
    };

karena itu adalah lubang keamanan yang menodai. Gagasan tainting adalah Anda hanya menggunakan __dangerousHTML sebagai kunci untuk input tepercaya . Tidak ada alasan mengapa this.props.html dipercaya.

Jika Dev A memahami tainting dan ingin membuat komponen yang dapat digunakan kembali yang menerima HTML sebagai prop, mereka akan membuatnya menerima objek {__dangerousHTML} itu sendiri. Maka terserah konsumen komponen itu untuk menentukan objek itu.

Gagasan tainting adalah Anda harus dapat mencari __dangerousHTML di basis kode Anda dan mengaudit setiap instance: apakah sisi kanan selalu aman? Tidak ada yang bisa menjamin bahwa __dangerousHTML: this.props.html akan aman. Namun, begitu Anda memiliki benda yang aman, Anda harus bisa menyebarkannya dengan bebas.

Mengenai React Native
Kami dengan anggun menurunkan jika perlu dan secara berbahayaSetInnerHTML tidak melakukan apa-apa. Saya tidak yakin saya melihat ada masalah dengan itu?

Ini tidak konsisten. Inkonsistensi tidak selalu jelas "buruk" tetapi biasanya memperlihatkan masalah yang lebih mendasar di API.

Saya pikir dalam skenario Anda, Dev A tidak sepenuhnya memahami cara kerja tainting.

Saya selalu berpikir bahwa penamaan " berbahaya SetInnerHTML" agak berat. Jangan mengurangi ketidakmampuan pengembang. Pengembang yang layak memahami injeksi dan semacamnya. Biarkan pengembang yang tidak berpengalaman dan/atau buruk membuat kesalahan.

Biarkan pengembang yang tidak berpengalaman dan/atau buruk membuat kesalahan.

React harus dapat diakses dan aman bagi pengembang dari semua tingkat keahlian. Mempermudah pengembang yang kurang berpengalaman untuk memperkenalkan masalah keamanan adalah buruk bagi mereka, penggunanya, dan komunitas React pada umumnya.

Pengembang dari semua tingkat pengalaman membuat kesalahan ini, terutama jika data melewati banyak lapisan dan sulit untuk mengatakan di mana itu dibersihkan dan seberapa kuat jaminannya.

Terlepas dari itu, mari kita pertahankan topik ini, dan hindari mengubah ini menjadi perdebatan tentang kegunaan penamaan yang menakutkan.

Satu kasus penggunaan untuk ini yang baru saja saya temui adalah ketika memigrasikan komponen non-React (sisi server) ke React components .

Mampu menyisipkan HTML yang dihasilkan dari komponen non-React secara langsung di dalam komponen React membuat migrasi lebih mudah (kita dapat mengambil langkah-langkah yang lebih kecil). Ini langsung jika Anda setuju dengan menambahkan elemen pembungkus di sekitar HTML (komponen non-React) Anda, tetapi itu mungkin merusak pengujian yang ada atau memiliki masalah halus lainnya.

Menambahkan dangerouslySetInnerHTML pada elemen induk tidak berfungsi jika Anda ingin memiliki elemen non-React dan React sebagai saudara kandung.

Saran Dans di atas sepertinya akan memungkinkan untuk ini, tanpa mengubah semantik Fragment dan sambil tetap jujur ​​tentang implikasi keamanan: https://github.com/facebook/react/issues/12014#issuecomment - 357673890

Saya selalu menggunakan metode filamentgroup loadCSS untuk memuat css non-kritis karena terakhir saya memeriksa, ia memiliki FOUT jauh lebih sedikit daripada metode lain (fontfaceobserver, Web Font Loader). Ketika mencoba memigrasikan situs lama saya untuk bereaksi (nextjs), saya menemukan bahwa elemen tautan tidak memiliki atribut onLoad yang sangat aneh bagi pengguna baru, hilangnya mereka secara misterius membuat saya sangat kesakitan. Saya merasa seperti saya membutuhkannya dan sangat tidak senang ada sesuatu yang menghapusnya tetapi saya tidak tahu apa yang harus saya lakukan. Apakah react atau nextjs menghapus atribut onLoad? Jika bereaksi, dapatkah Anda memberi saya cara praktik terbaik yang aman untuk mendapatkannya kembali sehingga saya dapat menggunakannya di _document.js saya untuk selanjutnya dikirim ke klien?

Bagaimanapun, sayang sekali begitu sulit bahkan untuk mengatasi masalah tersebut. Saya menemukan masalah ini selama pencarian google yang putus asa dan sangat menghargai semua orang yang telah memposting solusi di dalamnya. Saya mencoba melakukan Fragment HazardlySetInnerHTML sendiri bahkan sebelum mempelajari tiket ini. Bagaimana tiket ini dibuka begitu lama dan itu belum apa-apa? Saya jelas tidak ingin menambahkan div ke kepala saya jika tidak berfungsi di semua browser dan saya tidak tahu di mana harus meletakkan ParseHTML untuk memodifikasi teks menggunakan nextjs. Setelah duduk di sini untuk beberapa waktu khawatir bahwa mungkin tidak ada solusi praktis untuk masalah saya dan bertanya-tanya apakah saya telah membuat kesalahan yang mengerikan dalam memilih reaksi...ini datang kepada saya. Tutup tag skrip, masukkan yang Anda butuhkan, dan buka kembali:

<script dangerouslySetInnerHTML={{ __html: `</script>
    <link rel="preload" href="https://fonts.googleapis.com/css?family=Open+Sans" as="style" onLoad="this.onload=null;this.rel='stylesheet'" crossOrigin="anonymous"/>
<script>`,}}/>

Jelas Anda memiliki tag skrip yang tidak berguna di kepala Anda yang tidak diinginkan. html-react-parser sepertinya tidak berfungsi untuk saya ... onLoad masih dihapus yang saya butuhkan.

Tolong tim reaksi beri kami cara yang lebih baik untuk melakukan ini!!!!!!!

Mungkin saya dapat memberikan dua contoh di mana kami membutuhkan fitur seperti itu dalam proyek saya saat ini:

Komentar HTML bersarang di <div>

<div dangerouslySetInnerHTML={{ __html: `<!-- Released on ${BUILD_DATE} -->` }} />

akan mengeluarkan

<div>
  <!-- Released on [blabla] -->
</div>

Aku bisa hidup dengan itu, tapi itu tidak benar-benar memuaskan.

SSR dan menyuntikkan beberapa tag ke dalam

Klien kami bertanya apakah dia dapat menambahkan skrip ke situs web yang kami bangun dengan Next.js (pikirkan analitik, optimalkan...).

Kami membuat bidang teks scripts di CMS sehingga klien kami hanya akan menempelkan skrip berbeda yang dia dapatkan dari berbagai layanan yang mereka gunakan.

<div dangerouslySetInnerHTML={{ __html: header.scripts }} />

akan menghasilkan:

<head>
  ...
  <div>
    <script>/* ... analytics */</script>
    <script>/* ... optimizely */</script>
  </div>
</head>

yang jelas bukan HTML yang valid.

Kami berhasil memperbaikinya dengan html-react-parser , tetapi sangat mengganggu untuk menambahkan ketergantungan lain hanya untuk melakukannya dengan benar.

Saya membutuhkan sesuatu seperti ini dan menulis pengganti drop-in ini. https://github.com/jonathantneal/react-dom-fragment

Tidak ada elemen penampung dan pembaruan DOM ditambal. Itu dapat menambahkan sekitar 2kB ke ukuran bundel Anda, tetapi setengahnya karena saya harus membundel domdiff untuk menambal. Jadi, jika ada bagian yang dapat digunakan untuk meningkatkan React, saya akan dengan bebas menyerahkan kodenya.

Meskipun saya akan menyukai ini, saya tidak berpikir itu akan berhasil untuk semuanya.

Saya membuat SVG menggunakan React. Di dalam SVG ini ada 12 ikon SVG (lainnya ). Ikon SVG disediakan oleh API dan saya menempatkannya dengan {{dangerouslySetInnerHTML}}. Pada saat yang sama saya memposisikan ikon menggunakan atribut {{x}}- dan {{y}}-yang dihitung menggunakan rumus yang tidak jelas.

Jadi pada dasarnya saya menginginkan ini:

<svg width="400" height="400" viewBox="-200 -200 400 405">
  <React.Fragment
    x={iconPositionX}
    y={iconPositionY}
    dangerouslySetInnerHTML={({ __html: iconMarkup })}
  />
</svg>

Tapi apa yang terjadi dengan x/y ? Dengan mengizinkan hazardSetInnerHTML, Anda membuat kesan bahwa seseorang dapat menetapkan atribut pada React.Fragment .

Baik menghormati atribut (menempatkannya di node root dari hazardlySettedInnerHTML), atau tidak melakukan apa pun (tanpa atribut, tidak berbahayaSetInnerHTML) dan menghindari kebingungan

Datang ke sini dari pencarian Google dan tidak melihat kasus penggunaan khusus saya dicatat, jadi izinkan saya untuk menjelaskan:

Saya mencoba menggunakan React/JSX untuk templating sisi server dari situs statis. Saya memiliki banyak komponen reaksi yang diisi dengan set alat peraga awal dan kemudian server merendernya dan menuliskannya sebagai halaman situs saya. Masalahnya, selain halaman HTML, saya juga memiliki beberapa file yang bukan HTML tetapi saya masih ingin menggunakan JSX untuk templating. Misalnya, saya mencoba menulis file feed.json :

const React = require("react");

module.exports = ({ site }) => {
  const feed = {
    version: "https://jsonfeed.org/version/1",
    title: site.title,
    description: site.description
    // more here
  };

  return JSON.stringify(feed);
}

Dalam kode simpul saya, pada dasarnya saya mengulang setiap file "templat" komponen saya, merendernya, lalu menulis ke disk, yaitu

// looping through all files in my site and doing:
const stringToWrite = ReactDOMServer.renderToStaticMarkup(
  React.createElement(Component, siteData)
);

Untuk sebagian besar file template saya, ini berfungsi dengan baik. Ini menghasilkan banyak file .html statis. Tetapi, seperti yang dinyatakan, saya memiliki beberapa file yang ingin saya tulis yang bukan HTML. Kode di atas untuk feed.json menghasilkan sesuatu seperti ini:

{
  "version":"https://jsonfeed.org/version/1",
  // more here
}

Ketika saya melihat hasilnya, saya berpikir, "oh ya, React lolos dari string, saya harus menggunakan dangerouslySetInnerHTML ". Karena saya mencoba menulis file .json , saya tidak ingin mengeluarkan simpul aktual apa pun, jadi saya tahu <div dangerouslySetInnerHTML={}> tidak akan berfungsi. Lalu saya berpikir, "Saya bisa menggunakan Fragmen!" Dan saya mencobanya:

  return (
    <React.Fragment
      dangerouslySetInnerHTML={{ __html: JSON.stringify(feed) }}
    />
  );

Tapi itu tidak menghasilkan apa-apa. Jadi saya Google'd Fragment dengan HazardlySetInnerHTML dan di sinilah kita.

Mungkin ada cara yang lebih baik bagi saya untuk menangani ini dalam proyek saya dan saya belum cukup berpengalaman untuk memahami apa itu. Namun, saya menulis komentar ini untuk mengilustrasikan bagaimana pengembang dapat mengambil kesimpulan bahwa dangerouslySetInnerHTML pada Fragmen akan mendapatkan apa yang mereka inginkan.

Jadi dengan semua ini dikatakan, inilah +1 lain untuk semacam "mandiri" dangerouslySetInnerHTML

@martpie contoh adalah kasus penggunaan saya juga

Komentar HTML bersarang di a

<div dangerouslySetInnerHTML={{ __html: `<!-- Released on ${BUILD_DATE} -->` }} />

Ini akan memungkinkan alat manipulasi langsung untuk menggunakan komentar sebagai cara untuk melampirkan metadata ke node JSXText/JSXExpression/JSXElemenet. Akan senang untuk memiliki ini.

Pergi dengan https://github.com/remarkablemark/html-react-parser untuk saat ini.

Kasus penggunaan lain adalah memasukkan tag html google

<div dangerouslySetInnerHTML={{ __html: '<!--googleoff: snippet-->' }} />

Melakukannya seperti ini tidak benar saya kira*, jadi saya menganggap itu saat ini tidak mungkin?

*benar

<div>
<!--googleoff: snippet-->
content
<!--googleon: snippet-->
</div>

*salah

<div>
<div><!--googleoff: snippet--></div>
content
<div><!--googleon: snippet--></div>
</div>

Trik menggunakan RawHTML tampaknya tidak berfungsi di React 16.8.6 (karena itulah yang saya gunakan di sini dan sekarang):
https://codesandbox.io/s/nifty-breeze-5gbmy?fontsize=14

Tidak yakin bagaimana atau di mana ini pergi.

Oh, saya pikir saya salah memahami gagasan <RawHTML> . Itu hanya kode semu. Abaikan komentar saya di atas.

Kemungkinan solusi untuk markup di mana hanya satu elemen root yang mengurai hanya elemen root yang memulai dan menutup tag. Kemudian buat elemen reaksi dari mereka dan masukkan html bagian dalam dari elemen root itu ke dangerouslySetInnerHTML .

tautan ke inti

Untuk menambahkan kasus penggunaan lain (dari Guardian di sini). Kami meneruskan artikel sebagai 'elemen' (data terstruktur) melalui kabel dan kemudian memiliki aplikasi reaksi yang ingin merendernya sebagai HTML. Beberapa elemen terstruktur ini memiliki bidang 'html'. Kami tidak ingin dipaksa untuk menambahkan elemen pembungkus untuk kasus ini karena dapat memperburuk output HTML - misalnya jika kita memiliki beberapa elemen p diselingi dengan beberapa elemen img, idealnya output html akan mendekati:

p
p
img
p

Tapi sebaliknya kita berakhir dengan:

span(p)
span(p)
img
span(p)

dll.

Pilihan lain adalah bagi kita untuk melepaskan pembungkusnya secara manual

tag dari HTML bagian dalam tetapi ini adalah pendekatan yang cukup rapuh.

Saya pikir masalah ini harus melalui proses RFC kami daripada sebagai masalah dalam repositori GitHub ini.

Saya akan menutup masalah ini. Saya tahu telah ada beberapa diskusi yang baik di atas, tetapi karena tampaknya telah diselesaikan- saya pikir akan tepat untuk memasukkan poin-poin diskusi ke dalam proposal RFC.

@bvaughn Apakah seseorang benar-benar mengirimkan RFC untuk ini?

@jonnylynchy belum, saya akan pergi ke akhir pekan yang akan datang ... tetapi karena barang-barang saya yang dilaporkan #16931 juga ditutup, kesan saya adalah ini hanya beban tambahan, membuat saya merasa diabaikan.

Saya adalah salah satu pengelola UX Capture React binding (library instrumentasi) dan kami perlu menyuntikkan HTML ke dalam SSR-ed atau HTML yang dihasilkan secara statis sebelum hidrasi terjadi, khususnya untuk pembungkus <img> yang seharusnya melampirkan onload handler sebaris dengan elemen yang akan jauh lebih baik jika tidak membungkusnya.

Jika ada yang berpikir ini layak dilakukan, mengapa kita tidak melalui proses RFC untuk mencapai ini?

Saya tidak suka pembungkus <div></div> . Perubahan apapun?

Ada beberapa RFC terbuka (bahkan ditautkan): https://github.com/reactjs/rfcs/pull/129

@gaearon Saya mendapat kesalahan saat mengimpor: @types/react-dom"' has no exported member 'RawHTML'

@namlq93 Contoh Dan hanya untuk tujuan diskusi. RawHTML bukanlah sesuatu yang telah diimplementasikan di React.

Juga FWIW, tipe TypeScript juga tidak dikelola oleh tim React. Mereka berada dalam repo terpisah yang didorong oleh komunitas:
https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/react-dom