Freecodecamp: Tombol Code Locked / Unlocked adalah UX yang membingungkan untuk pemula

Dibuat pada 24 Jan 2018  ·  40Komentar  ·  Sumber: freeCodeCamp/freeCodeCamp



Deskripsi masalah

Tombol "Code Locked" pada beta muncul di tantangan pertama: "Say Hello to HTML Elements". Saya pikir ini ada hubungannya dengan peningkatan keamanan baru-baru ini untuk mencegah injeksi javascript melalui URI? Bagaimanapun, tidak ada kode di URI saya. URInya adalah https://beta.freecodecamp.org/en/challenges/basic-html-and-html5/say-hello-to-html-elements. Saya menebak mungkin itu karena kode tersimpan ditemukan di penyimpanan lokal? Memeriksa penyimpanan lokal untuk kode yang akan dieksekusi pasti jauh di luar kemampuan seseorang yang baru memulai kursus?

Karena ini tantangan pertama, ini pasti membingungkan dan di luar keahlian seorang pemula untuk memutuskan apakah kode itu aman atau tidak. Kami meminta mereka untuk membuat keputusan yang belum pernah mereka latih. Saya bahkan bingung sebagai developer yang berpengalaman. Apa yang harus saya cari untuk memahami jika kode tersebut dipercaya? Pastinya itu bukan elemen <h1> atau apa pun di editor teks?

Juga, tidak sesuai dengan instruksi yang berbicara tentang clicking the "Run tests" button" .

Bagaimana kami dapat meningkatkan pengalaman pengguna sambil tetap menjaganya tetap aman?

Informasi Browser

  • Nama Browser, Versi: Chrome, 63
  • Sistem Operasi: Ubuntu
  • Seluler, Desktop, atau Tablet: Desktop

Screenshot

image

UI critical path

Semua 40 komentar

@tchaffee terima kasih atas laporannya, menutup ini demi https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

@raisedadead Masalah # 16250 menjelaskan masalah yang berbeda. Perhatian saya adalah: bagaimana seorang pemula mengetahui apakah kode aman untuk dieksekusi atau tidak? Pengalaman pengguna buruk karena tidak mungkin seorang pemula memiliki informasi untuk membuat keputusan itu.

Oke… ini artinya kita butuh step challenge, untuk on boarding.

@QuincyLarson, apakah ada yang Anda pikirkan?

Atau mungkin meninjau kembali bagaimana kami awalnya menyediakan persyaratan ini? Apakah ada risiko menjalankan kode dari penyimpanan lokal? Saya mendapatkan peringatan bahkan ketika tidak ada kode di URI, dan itu sepertinya peringatan yang tidak perlu karena itu hanya pekerjaan saya yang disimpan.

Saya tidak tahu latar belakang kasus penggunaan ini, tetapi menurut saya kode di URI untuk berbagi? Dan saya rasa itulah risiko keamanan yang sebenarnya?

Mungkin kami dapat mempertimbangkan solusi lain untuk berbagi kode daripada meminta pemrogram pemula untuk memutuskan apakah kode aman untuk dieksekusi. Saya pikir akan sangat bermanfaat untuk terlebih dahulu memahami apa yang ditawarkan solusi yang ada dan apa persyaratan yang mengarah pada solusi kami saat ini. Atau mungkin saja berbagi kode melalui URI hanyalah ide yang buruk.

Atau mungkin meninjau kembali bagaimana kami awalnya menyediakan persyaratan ini? Apakah ada risiko menjalankan kode dari penyimpanan lokal? Saya mendapatkan peringatan bahkan ketika tidak ada kode di URI, dan itu sepertinya peringatan yang tidak perlu karena itu hanya pekerjaan saya yang disimpan.

Persyaratannya sudah mapan. Kami harus mengatasi beberapa masalah XSS pada produksi. Yang terbaru perlu memblokir berbagi sepenuhnya. Ada beberapa vektor tentang bagaimana kode yang tidak aman dapat dijalankan.

Seorang pengguna misalnya, bahkan dapat menyalin kode tempel dari mana saja, dan ini dalam praktiknya dapat menyebabkan masalah seperti itu. Perbaikan saat ini tidak mencegah vektor seperti itu, tetapi secara teknis membatasi eksekusi apa pun dengan peringatan tersebut. UX di sekitarnya tentu saja menjadi perhatian, dan karenanya membutuhkan jalur pembelajaran.

Mungkin kami dapat mempertimbangkan solusi lain untuk berbagi kode daripada meminta pemrogram pemula untuk memutuskan apakah kode aman untuk dieksekusi.

Tentu saja mengapa tidak. Jangan ragu untuk melihatnya dan kami ingin memiliki solusi yang menambah perbaikan saat ini yang pada dasarnya merupakan blok infra level pada eksekusi. Tentu saja, jika Anda tertarik, kami dapat menggunakan bantuan dengan PR.

Atau mungkin saja berbagi kode melalui URI hanyalah ide yang buruk.

Kami memiliki tempat sampah dalam rencana, tetapi itu tidak akan segera terjadi, karena kami sedang menyiapkan infra di sekitarnya. Lihat https://github.com/freeCodeCamp/freeCodeCamp/issues/11263

Ini seperti itu, ketika Pengguna adalah satu-satunya model, dan kami harus menjaga DB kami tetap ringan, kami berencana untuk membuatnya semakin terpisah secara progresif.

Persyaratannya sudah mapan.

Yang mana? Saya memahami bahwa mengambil kode dari penyimpanan lokal sebagai salah satu persyaratan. Itu masuk akal bagi saya - Campers tidak boleh kehilangan kode yang telah mereka mulai kerjakan.

Apakah ada persyaratan lain untuk menjalankan kode dari URI? Saya tidak tahu banyak tentang itu, itu hanya mengingatkan saya pada masalah keamanan yang saya lihat beberapa minggu yang lalu.

Mereka tampak seperti dua persyaratan yang berbeda dengan dua tujuan yang berbeda, dan risiko keamanan yang berbeda?

Jangan ragu untuk melihatnya dan kami ingin memiliki solusi yang menambah perbaikan saat ini yang pada dasarnya merupakan blok infra level pada eksekusi.

Saya bukan pakar keamanan, tetapi saya akan senang mencoba memberikan sesuatu jika saya dapat lebih memahami persyaratannya. Bisakah seseorang menjelaskan semua persyaratan secara rinci dari sudut pandang Camper, bersama dengan celah keamanan yang coba diperbaiki oleh perubahan terbaru? Juga, apa itu "blok infra level"?

Kami memiliki tempat sampah dalam rencana.

Masalahnya tidak menjelaskan solusi itu dengan cukup detail sehingga saya dapat memahami apa itu. Bisakah Anda memberi saya rincian lebih lanjut tentang apa itu "tempat sampah" dan apa solusi yang diharapkan?

Bagaimanapun, saya tidak ingin membuat ini menjadi sesuatu yang lebih besar dari itu. Mungkin tantangan langkah untuk orientasi adalah solusi yang tepat untuk saat ini. Tapi saya benar-benar ingin tahu seperti apa orientasi itu. Apakah mungkin untuk mengajari Camper sejak awal kode mana yang harus dipercaya dan mana yang tidak? Jika Anda memiliki sesuatu dalam pikiran saya ingin melihatnya karena mungkin itu lebih sederhana daripada yang saya bayangkan.

Terima kasih atas rasa ingin tahu Anda, tentang arsitektur proyek ini. Saya pasti ingin menjawab semua pertanyaan Anda, tetapi saya khawatir, menjelaskan semua yang ada di utas ini tidak akan cukup atau dibenarkan.

Saya memahami bahwa Anda mungkin memulai dengan ini, jadi saya akan mencoba menjelaskan sejelas mungkin, tetapi harap hilangkan pertanyaan Anda jika ada sesuatu yang tidak jelas.

Saya akan mengambil kueri ini dan mencoba memberi Anda konteksnya:

Bisakah seseorang menjelaskan semua persyaratan secara rinci dari sudut pandang Camper, bersama dengan celah keamanan yang coba diperbaiki oleh perubahan terbaru? Juga, apa itu "blok infra level"?

  • Pertama, ada perbedaan besar tentang bagaimana kode dievaluasi dan dijalankan dalam produksi (freeCodeCamp.org) dan pementasan (beta.freeCodeCamp.org) di sisi klien. Membahas itu sedikit di luar ruang lingkup, jadi saya akan menyarankan untuk melihat kodenya. Tapi, hanya untuk memberi Anda gambaran umum tentang prosesnya, itu mengambil kode di editor dan mengeksekusinya dalam konteks browser (menggunakan eval , merujuk kode ) meskipun dengan cara yang sangat berbeda.

  • Sekarang, datanglah ke perspektif pekemah. Bayangkan semua skenario yang akan Anda lakukan sebagai kemping:

    • Anda dapat mulai mengedit kode di editor Anda.
    • Anda dapat menempelkan kode di editor Anda
    • Anda dapat mengedit sebagian, pindah ke tantangan lain dan kembali.
    • Anda dapat mengunjungi profil seseorang, mengklik link lihat solusi, atau mengklik link di forum, dll. Atau dikenal sebagai URI.
    • Anda bisa ...
      atau kombinasi apa pun di atas juga dimungkinkan.
  • Dalam semua kasus, ini mencapai editor yang sama tempat kode akan diurai dan dievaluasi.
  • Penguraian ini bisa dari kode yang diketik, penyimpanan lokal atau URI.
  • Dalam semua kasus, beberapa pemeriksaan keamanan akan dilakukan, misalnya perlindungan loop tak terbatas, menghapus dan / atau mengganti tag saat mengkodekan solusi sebelum mengirim ke DB, dll.

  • Dengan no. kombinasi sangat kompleks untuk menangani beberapa vektor serangan.

  • Itu hanya keamanan.

  • Kemudian, muncul alur kerja:

    • penyimpanan lokal diperlukan untuk memiliki beberapa cara, untuk "menyimpan otomatis" bekerja, tanpa menekan DB.
    • Begitulah, karena hanya solusi yang diajukan dan lulus yang harus masuk ke DB.
    • Solusi parsial (diedit atau disalin-tempel), yaitu (Dikirim + TIDAK Lulus atau Sedang dikerjakan) harus ada di penyimpanan lokal.
    • Selain itu, transaksi (berbagi / melihat URI) antara DB dan penyimpanan lokal perlu dienkode / didekode untuk alasan yang saya sebutkan sebelumnya.

Di sini dengan transaksi yang saya maksudkan mencapai keadaan di mana, editor memiliki kode, yang ada karena pengguna mengklik tautan bersama dari profil mereka atau di tempat lain.

Prioritas solusi pemuatan untuk evaluasi adalah Editor > Local Storage > URI/DB

Jika, Anda membandingkan skenario vs alur kerja, Anda mungkin akan mendapatkan lebih banyak ide betapa rumitnya logika tersebut, sambil menjaga vektor serangan tetap di tempat.

Karenanya, pemeriksaan menyeluruh adalah tidak menjalankan apa pun di editor pada semua tantangan, tanpa persetujuan eksplisit, melalui metode Buka Kunci. Ini adalah blok infra tingkat yang saya ambil. Ini tidak akan kemana-mana, sampai ada cara yang aman untuk mengeksekusi semua kode dalam lingkungan yang terisolasi di browser.

Saya setuju ini mungkin buruk untuk UX. Karenanya, orientasi bisa menjadi cara, untuk menunjukkan, mengapa hal ini diperlukan, tanpa menjadi terlalu rumit, dan menakut-nakuti pengguna baru.

Akhirnya, tempat sampah akan menjadi sesuatu yang mirip seperti tautan pendek , Anda bisa lihat di mana. Contoh: codepen, jsbin dll. Catatan: Saya menyederhanakan gagasan di sini.

Ini dapat membantu kami, menyimpan / melihat kode dengan aman tanpa overhead prioritas saat ini.

BEGITU,

Perbaikan UX yang sebenarnya hanya menjelaskan peringatan tersebut, dalam tantangan on-boarding.

Tolong, perhatikan bahwa saya mungkin memiliki lebih dari hal-hal yang disederhanakan di sini. Jika Anda tertarik, saya sarankan untuk memeriksa kode. Jika macet, kami terbuka untuk menyampaikan pemahaman apa pun di bagian depan itu. Jadi silakan masukkan pertanyaan apa pun di sini.

Sekali lagi hanya untuk mengulang:

  1. Ya, ada beberapa persyaratan, tetapi semuanya memiliki titik masuk yang sama untuk pelaksanaan / evaluasi dan penayangan. Karenanya ada kebutuhan untuk mengunci / membuka kunci. Semuanya mengarah pada risiko keamanan yang sama.
  2. Ini untuk sekarang, pemeriksaan menyeluruh pada semua jalur masuk kode ke dalam mekanisme evaluasi.
  3. Kami pasti perlu menangani UX sebagai beberapa bentuk pembelajaran:

Apakah mungkin untuk mengajari Camper sejak awal kode mana yang harus dipercaya dan mana yang tidak? Jika Anda memiliki sesuatu dalam pikiran saya ingin melihatnya karena mungkin itu lebih sederhana daripada yang saya bayangkan.

  1. Kode, camper yang dibuat untuk solusi tantangan (baik dengan mengetik secara manual, atau salin / tempel dari editor lain) dipercaya.

  2. Kode, yang dibuat oleh orang lain (termasuk tautan dari profil mereka sendiri), TIDAK dipercaya, dan harus ditinjau sekali. Mereka dapat dengan mudah memeriksa apakah solusi di editor masuk akal bagi mereka. Karena, jika mereka membuka kode acak apa pun, tanpa memahami apa itu, mereka mungkin mempertaruhkan beberapa kemungkinan penjaga keamanan keamanan.

Kami hanya perlu mempersiapkan verbiage seputar dua poin di atas, dan menciptakan tantangan orientasi.

Semoga ini memberi Anda beberapa konteks? Jika tidak, silakan menambahkan lebih banyak pertanyaan. Selamat berkontribusi!

@raisedadead Penjelasan rinci Anda sangat membantu. Saya memiliki beberapa pertanyaan / pengamatan lagi yang saya harap akan membawa kita pada implementasi jangka pendek dan jangka panjang yang terbaik.

itu mengambil kode di editor dan menjalankannya dalam konteks browser (menggunakan eval

Itulah titik lemah menciptakan masalah keamanan. Saya tidak mengatakan itu dapat dihindari, tetapi hanya mencatat bahwa itu adalah sesuatu untuk dipikirkan seandainya seseorang di luar sana menemukan cara yang lebih aman untuk menyediakan fungsi yang sama. Mungkin bukan karena pada akhirnya Anda harus mengeksekusi kode. Tapi mari kita tetap berpikiran terbuka tentang itu. Saya akan berkomitmen untuk bertanya.

Mari kita lihat lebih dekat pada fungsionalitas dan persyaratan:

Solusi parsial (diedit atau disalin-tempel), yaitu (Dikirim + TIDAK Lulus atau Sedang dikerjakan) harus ada di penyimpanan lokal.

Kode, camper yang dibuat untuk solusi tantangan (baik dengan mengetik secara manual, atau salin / tempel dari editor lain) dipercaya.

Dari penjelasan di atas, menurut saya kode dari penyimpanan lokal harus dipercaya tetapi tidak dipercaya. Adakah cara untuk membedakan antara kode yang berasal dari URI (jelas tidak tepercaya) dan kode yang saya ketikkan sebelumnya yang berasal dari penyimpanan lokal saya? Perubahan kecil itu saja akan membuat UX jauh lebih baik. Terutama karena kita bisa membuat pesan menjadi jauh lebih spesifik: "Anda menggunakan URI dengan kode di dalamnya, apakah Anda mempercayai kodenya?"

Jika dimungkinkan untuk mendeteksi dan tidak mempercayai hanya kode yang berasal dari URI, maka saya pikir itu bisa cocok dengan alur kerja dan fungsionalitas yang ada. Jika kode memang berasal dari URI, kami tidak akan menyimpan kode apa pun ke penyimpanan lokal sampai pengguna menekan tombol "Code Locked / Unlock?" tombol. Setelah itu pengguna menunjukkan bahwa mereka mempercayai kode tersebut, sehingga dapat dengan aman disimpan di penyimpanan lokal dan kemudian dijalankan tanpa peringatan di masa mendatang ketika mereka kembali.

Jangka panjang, saya pasti mempertanyakan apakah mengirimkan kode dalam URI hanyalah ide yang buruk secara keseluruhan, dan apakah kami dapat menemukan cara yang lebih baik untuk berbagi solusi dan kode. Tetapi saya akan tegaskan bahwa itu adalah pertanyaan jangka panjang karena membutuhkan beberapa perubahan besar dalam cara yang dilakukan saat ini.

Mereka dapat dengan mudah memeriksa apakah solusi di editor masuk akal bagi mereka.

Ini membuat saya yakin bahwa orientasi bisa cukup sederhana untuk menjadi efektif. "Jika Anda tidak mengenali atau memahami kode di editor, jangan percaya."

Tetapi jika mungkin untuk membedakan antara kode yang berasal dari URI dan kode di penyimpanan lokal, maka saya bahkan mempertanyakan apakah on-boarding diperlukan, karena peringatan hanya dalam situasi itu tidak tampak seperti UX yang buruk bagi saya. "Anda baru saja menggunakan kode dari URI, pastikan kode di editor masuk akal sebelum Anda membukanya."

@raisedadead Saya tidak tahu apakah Anda pernah bertemu @tchaffee sebelumnya, tetapi dia adalah kontributor yang produktif untuk freeCodeCamp. Dia adalah pengembang berpengalaman, dan salah satu orang utama di balik proyek baru kami yang dapat diuji .

Oke… ini artinya kita butuh step challenge, untuk on boarding.

Kami tidak ingin menambahkan tantangan langkah lagi. Jika ada, kami ingin menyingkirkan tantangan langkah yang kami miliki.

Ini karena orang tidak membaca .

Salah satu alasan kami mencoba membuat teks pelajaran tantangan sesingkat mungkin adalah karena semakin banyak teks, semakin kecil kemungkinan pengguna memiliki kesabaran untuk membacanya.

@tchaffee benar - kami perlu meningkatkan UX ini.

Saya mengusulkan agar kita hanya mengunci kode jika mereka telah sampai pada tantangan dengan mengklik URL yang berisi kode orang lain. Jika tidak, kita tidak boleh memperingatkan mereka tentang menjalankan kode.

JSBin, CodePen, saya rasa tidak ada situs-situs ini yang memperingatkan orang-orang tentang menjalankan kode orang lain seperti ini. Saya pikir kami dapat memperingatkan mereka, tetapi hanya dalam situasi di mana kemungkinan mereka menjalankan kode yang bukan milik mereka. Jika tidak, mengklik tombol itu sangat mengganggu dan akan meningkatkan gesekan.

Anda dapat mulai mengedit kode di editor Anda.

Tidak perlu kunci.

Anda dapat menempelkan kode di editor Anda

Tidak perlu kunci (kami anggap Anda sudah membaca kode yang Anda tempelkan)

Anda dapat mengedit sebagian, pindah ke tantangan lain dan kembali.

Tidak perlu kunci

Anda dapat mengunjungi profil seseorang, mengklik link lihat solusi, atau mengklik link di forum, dll.

Ini adalah satu-satunya situasi ketika kunci dibutuhkan.

Selain itu, kita perlu menata ulang ini ke tempat yang tidak memerlukan pesan hover. Kami tidak menggunakan pesan saat diarahkan ke mana pun dalam basis kode, dan tidak seharusnya karena pesan tersebut tidak berfungsi di perangkat seluler. Semua teks yang ingin kita gunakan harus ditulis pada tombol itu sendiri.

basic_javascript__increment_a_number_with_javascript___freecodecamp_

Semua teks yang ingin kita gunakan harus ditulis pada tombol itu sendiri.

Saya pikir teks tombol yang ada dapat berfungsi jika Anda juga menampilkan tautan di bawah tombol di sepanjang baris "Mengapa kode saya dikunci?". Hanya sebuah saran.

Selain itu, saya dapat mencoba menangani masalah ini jika tidak ada orang lain yang memiliki waktu untuk itu. Saya memerlukan bantuan jika seseorang mengarahkan saya ke semua kode yang relevan. Tetapi jika ada seseorang yang lebih berkualitas dan mau maka pasti biarkan mereka mengambil masalah ini.

@tchaffee Itu akan luar biasa!

Alih-alih memiliki tautan, kita hanya perlu mencari cara ringkas untuk menjelaskannya dalam kata-kata sesedikit mungkin, meskipun tombolnya terdiri dari dua baris. "Saya percaya kode ini. Buka kuncinya."

Sekali lagi, kami hanya ingin tombol ini muncul jika kodenya bukan kemping.

@QuincyLarson ya, sementara saya juga ingin menghindari aliran

Itu masih menyisakan fakta bahwa sesuai dengan logika sisi klien saat ini, penerapan pemblokiran hanya kode non-pengguna yang harus diterapkan.

Yang saya maksud adalah logika untuk tombol "I trust this code. Unlock it." agar dapat ditampilkan hanya jika kode berasal dari URI, dll. Masih perlu diimplementasikan.

Saya akan menambahkan PR untuk memperbarui label dan menutup masalah lainnya https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

Itu masih menyisakan fakta bahwa sesuai dengan logika sisi klien saat ini, penerapan pemblokiran hanya kode non-pengguna yang harus diterapkan.

Tidak yakin di mana ini meninggalkan tawaran saya untuk menerapkan perilaku baru. Saya dapat mencoba menerapkan pemblokiran hanya kode non-pengguna, tetapi sepertinya sekarang bukan waktu yang tepat? Bisakah seseorang menjelaskan?

Saya harus memeriksa ulang, cara kerjanya untuk memberi Anda panduan yang sangat spesifik tentang apa yang harus dilakukan, sementara itu saya akan memberi tag @BerkeleyTrue untuk masukannya.

Maksud saya, logika untuk tombol "Saya percaya kode ini. Buka kuncinya." agar dapat ditampilkan hanya jika kode berasal dari URI, dll. masih perlu diterapkan.

@raisedadead Ya - Saya setuju dengan Anda. Melakukan hal itu penting dan akan menyelamatkan ribuan pekemah kewarasan mereka.

Saya telah memindahkan ini ke "jalur kritis" pada rilis beta Kanban kami: https://github.com/freeCodeCamp/freecodecamp/projects/1?fullscreen=true

Saya masih senang untuk mencobanya jika seseorang dapat mengarahkan saya ke bagian kode yang dipermasalahkan. Saya yakin saya bisa menemukannya sendiri, tetapi jika seseorang sudah terbiasa dengan kode itu akan menghemat waktu. Bisakah seseorang memberi tahu saya tentang status ini?

@tchaffee Terima kasih atas kesabaran Anda.

@Bouncey Tahukah Anda di mana logika ini berada di basis kode? Bisakah Anda mengarahkan @tchaffee ke arah yang benar?

@tokopedia

Anda dapat memeriksa URI dengan pathnameSelector

Anda menggunakannya dengan meneruskannya ke metode mapStatetoProps dari komponen SidePanel , Anda kemudian dapat berinteraksi dengan komponen ToolPanel dari sana

Semoga ini bisa membantu 👍

Saya mulai melihat ini dan saya punya pertanyaan. Adakah yang bisa memberi saya contoh bagaimana mungkin melakukan hal berikut:

Anda dapat mengunjungi profil seseorang, mengklik link lihat solusi, atau mengklik link di forum, dll. Atau dikenal sebagai URI.

Di situs beta saya hanya melihat munculan untuk solusi dan tidak ada URI yang memuat kode. Jadi sepertinya ini telah berubah di Beta? Apakah ada tempat lain di mana kode dapat dimuat dari URI? Bisakah seseorang mengarahkan saya ke contoh URI?

Terima kasih!

@tchaffee benar, kasus penggunaan ini tidak lagi valid:

Anda dapat mengunjungi profil seseorang, mengklik link lihat solusi, atau mengklik link di forum, dll. Atau dikenal sebagai URI.

Ini memang telah diganti dengan modal sekarang, membuatnya lebih aman daripada harus mengurai URI di editor. Jadi saya pikir memuat dari URI tidak ada lagi dalam gambar.

Sekarang, ini membawa kita ke Code Locking / Unlocking. Saat itulah tombol harus ditampilkan.

Berikut beberapa skenario yang dapat saya pikirkan:

  1. Campers dapat mengunjungi kembali tantangan, dari Peta.
  2. Dalam kasus seperti itu, kode akan dimuat di editor dari penyimpanan lokal, jika tersedia.
  3. Atau, itu akan diambil dari backend, ditambahkan ke penyimpanan lokal dan kemudian ditempatkan di editor.

Sekarang, dalam dunia yang ideal akan menjadi kasus, bahwa kode ini dimiliki oleh pekemah.

Tapi, untuk kemungkinan apapun, itu adalah Kode yang dimuat di editor, dan dijalankan. Ini meninggalkan kita dengan tempat di mana kode yang tidak aman dapat dieksekusi? Setidaknya itu adalah vektor yang bisa saya lihat.

Jadi, kami harus memastikan bahwa Camper mengetahui apa yang akan dilakukan, dan dilakukan dengan persetujuan eksplisit.

Jadi, bagian dari pemblokiran kode dari penyimpanan lokal atau backend (kode non-pengguna) masih ada, saya kira. Tapi, saya pikir memiliki tombol untuk itu tidak perlu.

Harus dimungkinkan untuk mengunci kode non-pengguna, yang tidak menjalankannya, jika itu selain kode seed asli atau sesuatu yang diketikkan oleh camper (kode-pengguna).

@Bouncey @BerkeleyTrue Apakah saya benar dalam pandangan ini?

Oh, ya dan hanya untuk dicatat bahwa penguraian URI masih tersedia, dan tidak ke mana-mana karena editor tantangan tidak menyukai fakta bahwa kami memiliki tampilan profil reaksi dengan modal untuk solusi.

Saya akan mencoba dan membagikan contoh URI jika saya punya waktu.

Tapi, untuk kemungkinan apapun, itu adalah Kode yang dimuat di editor, dan dijalankan. Ini meninggalkan kita dengan tempat di mana kode yang tidak aman dapat dieksekusi?

Saya akan mengatakan tidak. Jika seorang kemping menyalin / menempel kode dari tempat lain, mereka harus memastikan bahwa mereka memahami kodenya, dan bahwa kodenya aman. Pendekatan ini juga menghargai kejujuran dan menghukum kecurangan - jika Anda tidak memahami kode yang disalin, Anda tidak boleh menempelkannya. Anda jelas tidak bisa menulisnya sendiri jika Anda tidak memahaminya, jadi kerusakan yang Anda timbulkan adalah hasil dari kecurangan yang nyata.

Hanya ada dua cara "jujur" untuk memasukkan kode ke editor untuk pertama kalinya ?

  1. Salin / tempel sesuatu yang Anda pahami dan mungkin bisa Anda tulis sendiri.
  2. Ketik sendiri kodenya.

Pada titik mana itu disimpan ke penyimpanan lokal atau backend?

Kode apa pun yang berasal dari penyimpanan lokal atau backend dan ditempatkan di editor, pertama-tama harus berasal dari salah satu metode di atas. Jadi kode dari penyimpanan lokal atau backend selalu dapat dianggap aman.

Harus dimungkinkan untuk mengunci kode non-pengguna, yang tidak menjalankannya, jika itu selain kode seed asli atau sesuatu yang diketikkan oleh camper (kode-pengguna).

Sesuai di atas, IMO ini tidak diperlukan.

penguraian URI masih tersedia, dan tidak ke mana-mana karena editor tantangan tidak memahami fakta bahwa kita memiliki tampilan profil reaksi dengan modal untuk solusi.

Ini adalah satu-satunya vektor tidak aman yang dapat saya pikirkan. Jika Anda dapat memberi saya contoh, saya akan mencoba mendeteksi ini dan menunjukkan tombol "Buka" hanya dalam kasus ini.

Tentu saja jika saya melewatkan sesuatu, mohon koreksi saya.

Ya, dua poin pertama yang Anda nyatakan adalah skenario kasus terendah untuk mengunci kode, yang saya setuju. Dan sementara idealnya kita harus memblokirnya. Ini hal yang mahal untuk dilakukan.

Pada titik mana itu disimpan ke penyimpanan lokal atau backend?

Ini disimpan segera setelah kode apa pun tersedia di editor. Jadi copy paste dan ketik dihitung di dalamnya.

Ini adalah satu-satunya vektor tidak aman yang dapat saya pikirkan. Jika Anda dapat memberi saya contoh, saya akan mencoba mendeteksi ini dan menunjukkan tombol "Buka" hanya dalam kasus ini.

Ini satu-satunya kasus yang perlu ditangani. Dan sekali lagi ini bukan prioritas untuk saat ini. Kasus penggunaan untuk ini akan dikatakan ketika kami memiliki solusi yang berasal dari integrasi pihak ketiga ke aplikasi web kami melalui URI.

Jadi, pemeriksaan yang dilakukan sudah cukup, dan seperti yang Anda ketahui dengan benar, kita harus dengan cerdas memblokir ini saja.

Saya akan membagikan contoh URI secepatnya. (Stuart jika Anda mampu, jangan ragu untuk mengalahkan saya dalam hal ini)

@raisedadead terima kasih atas klarifikasinya. Saya setuju bahwa kita hanya perlu mengunci tombol saat pengguna pertama kali memuat tantangan dan ada parameter kode di URL. Dalam semua situasi lain, kita tidak boleh mengunci kode, dan hanya menjalankannya saat pengguna mengklik tombol atau menekan ctrl + enter untuk pertama kali.

Segera setelah seseorang dapat memberi saya contoh kode di URL, saya dapat mulai mengerjakannya.

@tchaffee Kami menguji kode dalam URI di sini .

Anda dapat mengirimkan tindakan untuk mengunci kode di blok if seperti ini

return Observable.of(
  makeToast({
    message: 'I found code in the URI. Loading now.'
  }),
  storedCodeFound(challenge, finalFiles),
  // lockTheCodeAction()
);

yang akan membuat Anda tetap produktif hingga kami dapat memberikan URI kode untuk Anda mainkan

@tchaffee Berikut adalah contoh URL: http: // localhost : 3000 / challenge / Check% 20for% 20Palindromes? solution = function% 20palindrome (str)% 20% 7B% 0A% 20% 20str% 20% 3D% 20str.toLowerCase () .replace (% 2F% 5B% 5CW_% 5D% 2Fg% 2C% 20% 27% 27)% 3B% 0A% 20% 20untuk (var% 20i% 20% 3D% 200% 2C% 20len% 20% 3D % 20str.length% 20-% 201% 3B% 20i% 20% 3C% 20len% 2F2% 3B% 20i% 2B% 2B)% 20% 7B% 0A% 20% 20% 20% 20if (str% 5Bi% 5D % 20!% 3D% 3D% 20str% 5Blen-i% 5D)% 20% 7B% 0A% 20% 20% 20% 20% 20% 20return% 20false% 3B% 0A% 20% 20% 20% 20% 7D % 0A% 20% 20% 7D% 0A% 20% 20return% 20true% 3B% 0A% 7D

Ini akan mengarah ke URL http: // localhost : 3000 / challenge / check-for-palindromes dan mengisi kode berikut:

function palindrome(str) {
  str = str.toLowerCase().replace(/[\W_]/g, '');
  for(var i = 0, len = str.length - 1; i < len/2; i++) {
    if(str[i] !== str[len-i]) {
      return false;
    }
  }
  return true;
}

@QuincyLarson Terima kasih. Saya ragu untuk mulai mengerjakan ini tanpa bisa menguji pekerjaan saya. Saya dapat menyisihkan waktu untuk melihat ini segera.

@tchaffee Luar

URL sebenarnya yang perlu saya gunakan adalah http: // localhost : 3000 / id / challenge / javascript-algoritme-and-data-structure-projects / palindrome-checker? Solution = function% 20palindrome (str)% 20% 7B% 0A % 20% 20str% 20% 3D% 20str.toLowerCase (). Ganti (% 2F% 5B% 5CW_% 5D% 2Fg% 2C% 20% 27% 27)% 3B% 0A% 20% 20for (var% 20i% 20 % 3D% 200% 2C% 20len% 20% 3D% 20str.length% 20-% 201% 3B% 20i% 20% 3C% 20len% 2F2% 3B% 20i% 2B% 2B)% 20% 7B% 0A% 20 % 20% 20% 20if (str% 5Bi% 5D% 20!% 3D% 3D% 20str% 5Blen-i% 5D)% 20% 7B% 0A% 20% 20% 20% 20% 20% 20return% 20false% 3B % 0A% 20% 20% 20% 20% 7D% 0A% 20% 20% 7D% 0A% 20% 20 kembali% 20 benar% 3B% 0A% 7D

Letakkan ini di sini untuk dokumentasi. Tidak perlu berkomentar.

@ Bouncey dapatkah Anda mengarahkan saya ke beberapa kode yang ada yang mengirimkan tindakan? Terima kasih.

Saya pikir semua penguncian / pembukaan kunci ini bukanlah ide terbaik dalam hal kode sandboxing. Sebagai gantinya, saya pikir Anda harus mengevaluasi kode di iframe pada asal yang berbeda untuk memastikan bahwa tidak ada cara untuk berinteraksi dengan sesi Camper.

(Selain tetapi sedikit relevan): Apa metode yang disukai untuk melaporkan potensi masalah keamanan ke freeCodeCamp?

@ joker314 jangan ragu untuk mengirimi saya email [email protected]

Perhatikan bahwa masalah ini diblokir oleh masalah # 16904

Saya menutup masalah ini karena sudah basi karena belum aktif belakangan ini. Jika menurut Anda ini masih relevan dengan platform yang baru diperbarui, harap jelaskan alasannya, lalu buka kembali.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

trashtalka3000 picture trashtalka3000  ·  3Komentar

jurijuri picture jurijuri  ·  3Komentar

robwelan picture robwelan  ·  3Komentar

raisedadead picture raisedadead  ·  3Komentar

QuincyLarson picture QuincyLarson  ·  3Komentar