のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,685,841人
頁
昨日: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してくれてるんだからそのくらい大丈夫よｂ

620 = :

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

621 = :

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

622 = :

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

623 = :

こいつ何いってんの

624 = :

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

625 = :

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

626 = :

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

627 = :

evalごときで威張るな

628 = :

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

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

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

629 = :

>>613
ｗｗｗ

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
なんか策に溺れるって感じだなｗ

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一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

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

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