のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,946人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレ+ JavaScript の質問用スレッド vol.128 +

    JavaScript覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    601 = :

    >>600
    >公共のネットワークで仕込まれたらそこを離れても改ざんされ続ける
    再接続で更新されるのにどうやって改ざんし続けるんだ?

    >主にメモリリソースのことを言ってる
    もっと具体的に頼む
    リソースを共有できる仕組みができてなぜ増える?

    602 = :

    > キャッシュポイズニングの中でもひどい例
    例えばDNSキャッシュサーバのポイズニングは
    銀行やショッピング系など高セキュリティを要するWebサイトをこれに瑕疵がなくとも書き換えうる点、
    攻撃者が対象Webサイトと被害ユーザの間にいる必要がない点や継続的集中的に攻撃可能な点など未対策の場合の攻撃難度
    攻撃成功時に当該DNSキャッシュサーバを利用する全員が被害を受けうる影響範囲の大きさ、
    そして末端の被害ユーザにおいて現実のカネの被害に容易に結びつくという被害の重大さ、これらからひどい例とわかる
    じゃServiceWorker on HTTPは?

    603 = :

    >>601
    >>再接続で更新される
    元々SWが用意されてないサイトであれば
    更新されることはないし、それ対策で用意しても今の仕様だと(OS)再起動までは残る

    >>もっと具体的に頼む
    例えばありとあらゆるサイトがSWを用意し、それがPush通知のために常に待機したとする
    当然そのサイトを開いていない時や、(設定によるが)ブラウザを閉じても生き続ける
    メモリが潤沢にない環境では支障が出ることは分かるだろう

    604 = :

    でどんだけリソース食うの? 主にメモリリソースと言うが
    Push通知待ち受けるプロジェクトごとに1つポート使うわけでもなし、1SWあたりせいぜい数KBじゃないの?

    605 = :

    っていうかこれ jsスレで言うのもなんだけど
    ユーザにとってはトラッキングの新しい手口でもあるんじゃないのか
    まずここだろ

    606 = :

    >元々SWが用意されてないサイトであれば
    >更新されることはないし、それ対策で用意しても今の仕様だと(OS)再起動までは残る
    ページで対策可能な状況を考えるなら登録解除してブラウザ再起動で消えるだろう

    >当然そのサイトを開いていない時や、(設定によるが)ブラウザを閉じても生き続ける
    ServiceWorkerは基本的に必要がなければ即死ぬ物だよ
    長期動作の機能は権限必須だし、ウェブアプリのためのもので一般的ではない

    ブラウザ拡張と同じ話を回りくどく言ってるだけにしか見えないが
    まさかそういう話じゃないだろ?

    607 = :

    >>604
    ブラウザによるが、適切にコードを書けば精々数KBで済む見込み

    >>606
    必要が無ければしぬがしなないようにもできるから問題なんだよ
    現時点でブラウザの設定必要だがブラウザを閉じても残り続けることはできる

    608 = :

    >>607
    可能だからなんて言ったら
    NaClのバックグラウンドプロセスのがよっぽど危険だな

    609 = :

    hoge = function(){
    this.a =1;
    this.b =2;
    this.c =3;;
    }
    という関数の最後に一文 alert(1);と「後から」付け加えたいのですが
    その場合
    hoge = function(){
    this.a =1;
    this.b =2;
    this.c =3;;
    alert(1);
    }
    ってthisの部分3つ書くしか方法は無いのでしょうか?
    配列みたいにalert(1)の部分だけappend出来ればいいなーと思ってるんですが 👀
    Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

    610 = :

    言ってることがよーわかりません

    612 = :

    >>810
    関数に一文追加したいって感じです

    613 = :

    よく考えればその設計にする必要ないんじゃないの?
    まあどうしてもしたければそういうAPI作ればいいんじゃないの?
    こんな感じで。
    Function.prototype.append = function (newFn) {
    return eval('('+(''+this).match(/(.+)}/)[1]+'\n'+(''+newFn).match(/{(.+)}/)[1]+'})')
    }

    615 = :

    >>609
    関数に一行加えるだけでいいよね?

    616 = :

    >>613
    クソコード書くな

    617 = :

    こういうコードが書けるからJSは生き残れてきたというのに

    618 = :

    開発者のわずかな面倒の回避のためにエンドユーザーは関数実行毎にevalさせられるのか
    悲しいな

    619 = :

    開発者のわずかな面倒の回避のためにエンドユーザーは
    巨大になったブラウザを毎月DLしてくれてるんだからそのくらい大丈夫よb

    620 = :

    eval薦めるやつなんてはじめてみた
    ひえー

    621 = :

    何でevalが駄目だと思ってるんだ?
    関数や特定テンプレートのコンパイル目的ならまさに使ってもいい事例だろう
    何かここの人たち変な先入観あるよね

    622 = :

    あ、>>613はクソコードだと思うよ
    eval抜きで

    623 = :

    こいつ何いってんの

    624 = :

    とりあえず、>>613 みたいなクソコードは書かないようにちゃんと勉強した方がいいと思うよ。

    625 = :

    evalを使いこなせて初めて一人前

    626 = :

    世の中キレイ事だけじゃ済まされない
    実用的な物事ほど汚いものさ

    627 = :

    evalごときで威張るな

    628 = :

    >>621
    > 何でevalが駄目だと思ってるんだ?

    強力な道具は危険性もある。
    それを使わないで出来ることならば、
    使わない方がいい。

    つまりは、適切な道具を選べないということがよくない。

    629 = :

    >>613
    www

    630 = :

    >>609
    function Hoge (properties) {
     for (var i = 0, keys = Object.keys(properties), l = keys.length, key; i < l; ++i) {
      key = keys[i];
      this[key] = properties[key];
     }
    }
    console.log(new Hoge({a: 1, b: 2, c: 3}));

    631 = :

    >>609
    function Hoge () {
     this.a = 1;
     this.b = 2;
     this.c = 3;

     if (arguments.length > 0 && typeof arguments[0] === 'function') {
      arguments[0]();
     }
    }
    console.log(new Hoge());
    console.log(new Hoge(alert.bind(this, 1)))

    632 = :

    >>631
    なんか策に溺れるって感じだなw

    633 = :

    >>609
    function Hoge () {
     this.a = 1;
     this.b = 2;
     this.c = 3;
    }
    function Hoge2 () {
     Hoge.call(this);
     alert(1);
    }
    console.log(new Hoge());
    console.log(new Hoge2());

    635 = :

    出来る出来ないかで言えば出来るで回答者はコード書いてるけど
    いっとくけどこんなコード書いてるやつが実際いたら殴るレベルだぞ

    636 = :

    requestAnimationFrame自体は重いかな?
    タブを最小化したときはとまるの?

    637 = :

    >>636
    requestAnimationFrame それ自体の処理コストに
    setTmeout と目に見える違いはないだろう

    スケジュール優先度をブラウザに任せるためにあるので
    最小化したときは間引かれると思われ。
    特にスマホ環境なら電源重視で間引かれるんじゃないか?

    638 = :

    >>637
    メリットはそれぐらいか。

    639 = :

    メリットは最も効率のよいタイミングで呼び出してくれること。

    640 = :

    >>628
    いいや積極的に使ったほうがいい場合もある
    初心者でもなければsanitizeや外のコードの入り込む余地は減らすし
    ただ慣習で否定するなんて馬鹿だろう

    641 = :

    これはnew Functionにも言える事
    動的な評価による最適化がほしいなら使っても良い

    642 = :

    積極的に使ったほうがいい場合「だけ」使えって言ってんだよ。
    まったく頭わるすぎ

    643 = :

    evalを使ったほうが良い事例なんてまずないからな。
    あるとしたらテンプレートエンジンぐらいなもんだろ。
    それ以外で使われてるのは悪とみなして良い

    644 = :

    使い所の分からない奴には使うなというのが無難だな。

    645 = :

    少なくとも>>613は使いどころじゃないだろう

    646 = :

    >>613は例外の発生条件が多すぎてまともに使えない
    関数を作り直すにしてもやり方を考えろといいたい
    http://jsfiddle.net/sgLr6684/

    647 = :

    >>644
    その通り。evalを使うのはテンプレートエンジンぐらいで
    それ以外に使い所はない。

    648 = :

    理論的に、eval のような動的生成関数は計算可能になるとは限らない
    逆に計算可能な動的生成関数は、おそらく宣言的な命令の集合体に変換できるので
    効率性が求められない限り、eval を使う必要はないだろう

    649 = :

    まーた自演してる

    650 = :

    evalは横着するときに便利
    例えば虫食い算を解くロジックを作る場合は
    穴あきの状態でJSコードに変換し、全ての場合を作って確かめればいい

    >>646
    コード制作依頼はお断りだよ
    .を[\s\S]に置き換えるくらいは自分でできなきゃ


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について