私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.128 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>600
>公共のネットワークで仕込まれたらそこを離れても改ざんされ続ける
再接続で更新されるのにどうやって改ざんし続けるんだ？
>主にメモリリソースのことを言ってる
もっと具体的に頼む
リソースを共有できる仕組みができてなぜ増える？
>公共のネットワークで仕込まれたらそこを離れても改ざんされ続ける
再接続で更新されるのにどうやって改ざんし続けるんだ？
>主にメモリリソースのことを言ってる
もっと具体的に頼む
リソースを共有できる仕組みができてなぜ増える？
> キャッシュポイズニングの中でもひどい例
例えばDNSキャッシュサーバのポイズニングは
銀行やショッピング系など高セキュリティを要するWebサイトをこれに瑕疵がなくとも書き換えうる点、
攻撃者が対象Webサイトと被害ユーザの間にいる必要がない点や継続的集中的に攻撃可能な点など未対策の場合の攻撃難度
攻撃成功時に当該DNSキャッシュサーバを利用する全員が被害を受けうる影響範囲の大きさ、
そして末端の被害ユーザにおいて現実のカネの被害に容易に結びつくという被害の重大さ、これらからひどい例とわかる
じゃServiceWorker on HTTPは?
例えばDNSキャッシュサーバのポイズニングは
銀行やショッピング系など高セキュリティを要するWebサイトをこれに瑕疵がなくとも書き換えうる点、
攻撃者が対象Webサイトと被害ユーザの間にいる必要がない点や継続的集中的に攻撃可能な点など未対策の場合の攻撃難度
攻撃成功時に当該DNSキャッシュサーバを利用する全員が被害を受けうる影響範囲の大きさ、
そして末端の被害ユーザにおいて現実のカネの被害に容易に結びつくという被害の重大さ、これらからひどい例とわかる
じゃServiceWorker on HTTPは?
>>601
>>再接続で更新される
元々SWが用意されてないサイトであれば
更新されることはないし、それ対策で用意しても今の仕様だと(OS)再起動までは残る
>>もっと具体的に頼む
例えばありとあらゆるサイトがSWを用意し、それがPush通知のために常に待機したとする
当然そのサイトを開いていない時や、（設定によるが）ブラウザを閉じても生き続ける
メモリが潤沢にない環境では支障が出ることは分かるだろう
>>再接続で更新される
元々SWが用意されてないサイトであれば
更新されることはないし、それ対策で用意しても今の仕様だと(OS)再起動までは残る
>>もっと具体的に頼む
例えばありとあらゆるサイトがSWを用意し、それがPush通知のために常に待機したとする
当然そのサイトを開いていない時や、（設定によるが）ブラウザを閉じても生き続ける
メモリが潤沢にない環境では支障が出ることは分かるだろう
でどんだけリソース食うの？ 主にメモリリソースと言うが
Push通知待ち受けるプロジェクトごとに1つポート使うわけでもなし、1SWあたりせいぜい数KBじゃないの？
Push通知待ち受けるプロジェクトごとに1つポート使うわけでもなし、1SWあたりせいぜい数KBじゃないの？
っていうかこれ jsスレで言うのもなんだけど
ユーザにとってはトラッキングの新しい手口でもあるんじゃないのか
まずここだろ
ユーザにとってはトラッキングの新しい手口でもあるんじゃないのか
まずここだろ
>元々SWが用意されてないサイトであれば
>更新されることはないし、それ対策で用意しても今の仕様だと(OS)再起動までは残る
ページで対策可能な状況を考えるなら登録解除してブラウザ再起動で消えるだろう
>当然そのサイトを開いていない時や、（設定によるが）ブラウザを閉じても生き続ける
ServiceWorkerは基本的に必要がなければ即死ぬ物だよ
長期動作の機能は権限必須だし、ウェブアプリのためのもので一般的ではない
ブラウザ拡張と同じ話を回りくどく言ってるだけにしか見えないが
まさかそういう話じゃないだろ？
>更新されることはないし、それ対策で用意しても今の仕様だと(OS)再起動までは残る
ページで対策可能な状況を考えるなら登録解除してブラウザ再起動で消えるだろう
>当然そのサイトを開いていない時や、（設定によるが）ブラウザを閉じても生き続ける
ServiceWorkerは基本的に必要がなければ即死ぬ物だよ
長期動作の機能は権限必須だし、ウェブアプリのためのもので一般的ではない
ブラウザ拡張と同じ話を回りくどく言ってるだけにしか見えないが
まさかそういう話じゃないだろ？
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)
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)
外の変数を参照してないならhoge.toString()して付け加えるとか
しているならhogeをラップするしかないんじゃない
しているならhogeをラップするしかないんじゃない
>>810
関数に一文追加したいって感じです
関数に一文追加したいって感じです
よく考えればその設計にする必要ないんじゃないの？
まあどうしてもしたければそういうAPI作ればいいんじゃないの？
こんな感じで。
Function.prototype.append = function (newFn) {
return eval('('+(''+this).match(/(.+)}/)[1]+'\n'+(''+newFn).match(/{(.+)}/)[1]+'})')
}
まあどうしてもしたければそういうAPI作ればいいんじゃないの？
こんな感じで。
Function.prototype.append = function (newFn) {
return eval('('+(''+this).match(/(.+)}/)[1]+'\n'+(''+newFn).match(/{(.+)}/)[1]+'})')
}
this.a =1;～this.c =3;;の部分を?外部に置いて使い回せばええんちゃう？
>>609
関数に一行加えるだけでいいよね？
関数に一行加えるだけでいいよね？
>>613
クソコード書くな
クソコード書くな
開発者のわずかな面倒の回避のためにエンドユーザーは関数実行毎にevalさせられるのか
悲しいな
悲しいな
開発者のわずかな面倒の回避のためにエンドユーザーは
巨大になったブラウザを毎月DLしてくれてるんだからそのくらい大丈夫よｂ
巨大になったブラウザを毎月DLしてくれてるんだからそのくらい大丈夫よｂ
何でevalが駄目だと思ってるんだ？
関数や特定テンプレートのコンパイル目的ならまさに使ってもいい事例だろう
何かここの人たち変な先入観あるよね
関数や特定テンプレートのコンパイル目的ならまさに使ってもいい事例だろう
何かここの人たち変な先入観あるよね
あ、>>613はクソコードだと思うよ
eval抜きで
eval抜きで
とりあえず、>>613 みたいなクソコードは書かないようにちゃんと勉強した方がいいと思うよ。
>>613
ｗｗｗ
ｗｗｗ
>>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}));
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}));
>>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)))
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)))
>>631
なんか策に溺れるって感じだなｗ
なんか策に溺れるって感じだなｗ
>>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());
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());
hoge();
alert(1);
の順番に呼び出すでいいだろ
なんで変なことしたがるのか
alert(1);
の順番に呼び出すでいいだろ
なんで変なことしたがるのか
出来る出来ないかで言えば出来るで回答者はコード書いてるけど
いっとくけどこんなコード書いてるやつが実際いたら殴るレベルだぞ
いっとくけどこんなコード書いてるやつが実際いたら殴るレベルだぞ
requestAnimationFrame自体は重いかな？
タブを最小化したときはとまるの？
タブを最小化したときはとまるの？
>>636
requestAnimationFrame それ自体の処理コストに
setTmeout と目に見える違いはないだろう
スケジュール優先度をブラウザに任せるためにあるので
最小化したときは間引かれると思われ。
特にスマホ環境なら電源重視で間引かれるんじゃないか？
requestAnimationFrame それ自体の処理コストに
setTmeout と目に見える違いはないだろう
スケジュール優先度をブラウザに任せるためにあるので
最小化したときは間引かれると思われ。
特にスマホ環境なら電源重視で間引かれるんじゃないか？
>>637
メリットはそれぐらいか。
メリットはそれぐらいか。
これはnew Functionにも言える事
動的な評価による最適化がほしいなら使っても良い
動的な評価による最適化がほしいなら使っても良い
積極的に使ったほうがいい場合「だけ」使えって言ってんだよ。
まったく頭わるすぎ
まったく頭わるすぎ
evalを使ったほうが良い事例なんてまずないからな。
あるとしたらテンプレートエンジンぐらいなもんだろ。
それ以外で使われてるのは悪とみなして良い
あるとしたらテンプレートエンジンぐらいなもんだろ。
それ以外で使われてるのは悪とみなして良い
少なくとも>>613は使いどころじゃないだろう
理論的に、eval のような動的生成関数は計算可能になるとは限らない
逆に計算可能な動的生成関数は、おそらく宣言的な命令の集合体に変換できるので
効率性が求められない限り、eval を使う必要はないだろう
逆に計算可能な動的生成関数は、おそらく宣言的な命令の集合体に変換できるので
効率性が求められない限り、eval を使う必要はないだろう
evalは横着するときに便利
例えば虫食い算を解くロジックを作る場合は
穴あきの状態でJSコードに変換し、全ての場合を作って確かめればいい
>>646
コード制作依頼はお断りだよ
.を[\s\S]に置き換えるくらいは自分でできなきゃ
例えば虫食い算を解くロジックを作る場合は
穴あきの状態で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 スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.125 + (1001) - [97%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.108 + (1001) - [97%] - 2013/9/21 15:16
- + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.120 + (1002) - [97%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.129 + (981) - [97%] - 2016/5/5 8:16
- + JavaScript の質問用スレッド vol.129 + (926) - [97%] - 2017/7/27 13:45
- + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.127 + (1001) - [97%] - 2016/2/4 0:15
- + JavaScript の質問用スレッド vol.127 + (160) - [97%] - 2021/7/16 9:30
- + JavaScript の質問用スレッド vol.126 + (952) - [97%] - 2015/11/18 13:15
- + JavaScript の質問用スレッド vol.126 + (348) - [97%] - 2023/1/12 17:00
トップメニューへ / →のくす牧場書庫について