回答編集履歴
4
誤字の修正
answer
CHANGED
@@ -105,15 +105,21 @@
|
|
105
105
|
|
106
106
|
> SPAではややロジックも担当している印象を受けたためこのような質問をしました。
|
107
107
|
|
108
|
+
追記1に重複する部分がいくつかありますが、重複する部分は追記1への回答を参照してください。
|
108
|
-
|
109
|
+
ユーザーに予め渡す情報量が多いのがSPAので、たしかにそのような懸念はあります。
|
109
110
|
|
111
|
+
まずはWebサイト全体で使う全ての情報を割り出し一覧化します。
|
110
|
-
|
112
|
+
次に各情報はどのレベルでガードしなければならないかを設定します。
|
111
|
-
これは公開しても良いだろう…といった情報ならばbundle.jsに含めて表示・非表示を切り替えれば良いです
|
113
|
+
これは公開しても良いだろう…といった情報ならばbundle.jsに含めて表示・非表示を切り替えれば良いですし、
|
112
|
-
|
114
|
+
公開出来ない情報は全てAjax通信で別途取りに行く設計にしてください。
|
113
115
|
|
114
|
-
|
116
|
+
あれもこれも非公開にしたければ、相応の数のAjax通信用のURL(エンドポイント)が必要になります。
|
115
117
|
手間や開発コストも吟味しながら取捨選択を行ってください。
|
116
118
|
|
117
119
|
もし認証情報を利用した部分以外、
|
118
120
|
例えばJSONファイルを展開してアンケートのフォーム部品を生成するロジックを非公開にしたい。
|
119
|
-
……という意図ならば、もうSPAは諦めてください。
|
121
|
+
……という意図ならば、もうSPAは諦めてください。
|
122
|
+
|
123
|
+
SPAで運営しているWebサイト・Webアプリは全て盗まれるリスクとのトレードオフで運営しています。
|
124
|
+
ですので、守るべき対象はサーバーに保存する個人情報やプロジェクト情報であり、
|
125
|
+
そこの部分でマネタイズしているから他社にbundle.jsを盗まれたとしてもダメージは軽微であるという判断を行っているからです。
|
3
もう少し、質問者さんがどう動けば良いのかを見据えた回答に調整
answer
CHANGED
@@ -64,23 +64,56 @@
|
|
64
64
|
|
65
65
|
> クライアントサイドレンダリングの場合は一旦全て送り、ユーザー側で非表示にさせるといった処理が考えられそうです。
|
66
66
|
|
67
|
+
SPAではない既存のWebアプリで
|
68
|
+
HTML情報上にWebサイトを利用する全てのユーザーの住所や氏名を`display: none;`の状態で埋め込んでおいて、
|
67
|
-
|
69
|
+
JavaScriptで表示・非表示を切り替える開発者がいますか?
|
68
|
-
Ajax通信で「私は女性なので、化粧のアンケートください」という申請を行い、
|
69
|
-
アンケート項目だけをJSONで受け取りDOMとして展開する作りにすることも可能です。
|
70
70
|
|
71
|
+
それと同じです。
|
71
|
-
|
72
|
+
bundle.js内にはそのユーザーが閲覧しても良い情報しか内包してはいけません。
|
73
|
+
貴方が考えている「一旦全て送り、ユーザー側で非表示にさせる」というのは
|
72
|
-
|
74
|
+
上記の全ユーザーの氏名や住所をJavaScript制御でON・OFFを切り替える発想と同じです。
|
73
75
|
|
76
|
+
> じゃあどうするのか?
|
77
|
+
|
78
|
+
Ajaxでそのユーザの権限下でアクセス出来る情報を別途取得してください。
|
79
|
+
bundle.jsにはAjax通信の結果(JSON)を解析して、アンケートフォームを作り出すロジックのみを埋め込んでください。
|
80
|
+
これで質問文にあった「男性に化粧品の情報を公開する」懸念は払拭されます。
|
81
|
+
|
82
|
+
「私に紐づくアンケートはある?」ということで、
|
83
|
+
`example.com/api/questionnaires`に向けてAjax通信を行います。
|
84
|
+
|
85
|
+
女性の場合だけ化粧品のアンケートを表示したいならば、
|
86
|
+
きっと認証情報には名前、性別、年齢等の情報はありますよね。
|
87
|
+
|
88
|
+
```JSON
|
89
|
+
[
|
90
|
+
{"name": "化粧品Aは既に利用されていますか?", "candidates": ["はい", "いいえ"]},
|
91
|
+
{"name": "化粧品Aを5点満点で評価してください", "candidates": ["1", "2", "3", "4". "5"]},
|
92
|
+
{"name": "化粧品Aのモニターに参加しますか?", "candidates": ["はい", "いいえ"]},
|
93
|
+
{"name": "化粧品Bは既に利用されていますか?", "candidates": ["はい", "いいえ"]},
|
94
|
+
{"name": "化粧品Bを5点満点で評価してください", "candidates": ["1", "2", "3", "4". "5"]},
|
95
|
+
{"name": "化粧品Bのモニターに参加しますか?", "candidates": ["はい", "いいえ"]},
|
96
|
+
]
|
97
|
+
```
|
98
|
+
|
99
|
+
男性の場合は空の配列を返せば化粧品の情報は送られません。
|
100
|
+
まぁ、別に男性に化粧品名くらい教えても大丈夫かとは思いますが、認証情報と脳内補完して回答しています。
|
101
|
+
|
74
102
|
---
|
75
103
|
|
76
104
|
【追記2への回答】
|
77
105
|
|
78
106
|
> SPAではややロジックも担当している印象を受けたためこのような質問をしました。
|
79
107
|
|
80
|
-
|
108
|
+
1の方に全部下記ましたが、ユーザーに予め渡す情報量が多いのがSPAですからね。
|
81
109
|
|
110
|
+
まずは画面部品の情報の一覧を割り出し、どのレベルでガードしなければならないかを設定します。
|
82
|
-
|
111
|
+
これは公開しても良いだろう…といった情報ならばbundle.jsに含めて表示・非表示を切り替えれば良いです。
|
83
|
-
|
112
|
+
その他、公開出来ない情報全てはAjax通信で別途取りに行く設計にしてください。
|
84
113
|
|
85
|
-
|
114
|
+
当然あれもこれも非公開にしたければ、相応のAjax通信用のURL(エンドポイント)は多くなります。
|
86
|
-
|
115
|
+
手間や開発コストも吟味しながら取捨選択を行ってください。
|
116
|
+
|
117
|
+
もし認証情報を利用した部分以外、
|
118
|
+
例えばJSONファイルを展開してアンケートのフォーム部品を生成するロジックを非公開にしたい。
|
119
|
+
……という意図ならば、もうSPAは諦めてください。
|
2
追記への対応
answer
CHANGED
@@ -40,4 +40,47 @@
|
|
40
40
|
ロールをちょっと切り替えるだけで引き出せる量が違うから不正されると困るという話であれば、
|
41
41
|
|
42
42
|
Webpack等が吐き出すJavaScriptファイル自体をAdmin用・エンドユーザー用に分けてしまっても良いと思います。
|
43
|
-
Admin用は少しくらい不具合が出ても問題になりにくいのでそんなに問題にはならないと思います。
|
43
|
+
Admin用は少しくらい不具合が出ても問題になりにくいのでそんなに問題にはならないと思います。
|
44
|
+
|
45
|
+
---
|
46
|
+
|
47
|
+
【追記1への回答】
|
48
|
+
|
49
|
+
そもそもブラウザの本質を理解していますか?
|
50
|
+
ブラウザはただ受け取ったHTML・CSS・JS・画像ファイルを内部的に展開して画面に表示しているだけです。
|
51
|
+
そしてWebサーバへHTTP通信を行いながらHTML・CSS・JS・画像ファイルをまた受け取る。
|
52
|
+
|
53
|
+
これがコマンドラインツールのcurlになった瞬間不正になるわけではありません。
|
54
|
+
全世界のWebサーバはHTTP通信を行う全てのクライアントが対象だからです。
|
55
|
+
|
56
|
+
> コンソールからコンポーネントに渡すデータを変えればそのコンポーネントの挙動を変更することとが可能だと思います。
|
57
|
+
|
58
|
+
Chromeと普通のWebサイトでも可能です。
|
59
|
+
デベロッパーツール等を利用さえすれば現状のDOM構造を好き勝手に歪めてリクエスト飛ばせますよね。
|
60
|
+
|
61
|
+
サービス提供元がわざわざHTMLを渡して上げてるのは、
|
62
|
+
この項目に従って回答してくださいね、回答が済んだら○○URLのポストに投函してくださいねという**ガイドライン**です。
|
63
|
+
クラッカーにはHTMLやJSでいくら頑張っても何の対策にもなりません。
|
64
|
+
|
65
|
+
> クライアントサイドレンダリングの場合は一旦全て送り、ユーザー側で非表示にさせるといった処理が考えられそうです。
|
66
|
+
|
67
|
+
例えばログインユーザーがアンケート画面のリンクをクリックしたら、
|
68
|
+
Ajax通信で「私は女性なので、化粧のアンケートください」という申請を行い、
|
69
|
+
アンケート項目だけをJSONで受け取りDOMとして展開する作りにすることも可能です。
|
70
|
+
|
71
|
+
男が「私も女性なので、化粧のアンケートください」って通信してきたらどうするか?
|
72
|
+
「認証してるユーザー確認したけどお前男じゃないかふざけんな」エラーを返せば解決です。
|
73
|
+
|
74
|
+
---
|
75
|
+
|
76
|
+
【追記2への回答】
|
77
|
+
|
78
|
+
> SPAではややロジックも担当している印象を受けたためこのような質問をしました。
|
79
|
+
|
80
|
+
というか、ユーザーに予め渡す情報量が多いのがSPAですからね。
|
81
|
+
|
82
|
+
誰にでも公開して良い情報は予めJSに全部含めて投げ渡してあげれば良いですが、
|
83
|
+
特定の人にしか渡してはいけないデータならば死ぬ気で守りましょう。
|
84
|
+
|
85
|
+
ほぼ全ての項目は追記1の手法を応用することで可能です。
|
86
|
+
難読化(uglify)も併用しながらしっかり設計を練って管理しましょう。
|
1
秀丸作者の下りが記憶と違って嘘になってたので修正
answer
CHANGED
@@ -28,7 +28,7 @@
|
|
28
28
|
自分のサービスの価値をどの程度守らなければならないのか検討してみるのも良いでしょう。
|
29
29
|
|
30
30
|
例えば、かの有名な秀丸エディタはパスワードを入力するだけで認証を突破出来る脆弱なシステムです。
|
31
|
-
しかし、その作者は「
|
31
|
+
しかし、その[作者は](http://hrnabi.com/2015/04/14/6878/)「学生やフリーソフトウェアの開発者は無料にしてあげたい、パスワードを変えたり電話対応したりするとコストが大変なので実質黙認状態、でもまとまったライセンスを買っていただける方もいらっしゃって幸いです」というゆるい対応をしています。
|
32
32
|
|
33
33
|
JSを解析して裏でconsole叩いて変な挙動出来るような人間ならば逆にコンタクトをとっても良いかもしれませんね。
|
34
34
|
日本的ではないかも知れませんが、引き入れれば優秀なメンバーとして活躍してくれるかもしれません。
|