K.Maebashi's BBS

ご自由に書き込んでください。雑談も可。
テスト書き込みの類はテスト用掲示板にどうぞ

[日付順表示] [日付順インデックス] [スレッド順インデックス]

新規投稿 | 開設者ホームページへ戻る | ヘルプ

[2106] Re:リストA-13の ”~Impl” について
投稿者:(ぱ)こと管理人
2018/02/18 13:16:18

>せっかく抽象型を用意しているのであれば、ここは抽象型の変数定義にするのではと >思ったのですが、サブクラスの変数定義を使用している理由があれば、 >教えて頂きたいです。 これは私の流儀であって、Javaでの一般的な書き方かというとそうでもないかも しれませんが、私は、Javaでパッケージを分ける規模のプログラムを書くときは、 パッケージ単位でインタフェースと実装を分けるようにしています。 たとえばHttpServletRequestクラスであれば、インタフェースを com.kmaebashi.henacat.servletに、実装を com.kmaebashi.henacat.servletimplに置いています。 そして、HttpServletRequestの利用者(この場合はサーブレットのプログラムを書く人) にはインタフェース側だけをimportしてもらうようにします。Cookieのような 簡単なクラスを除き、インタフェース側のパッケージには実装は置きません。 こうすることで、利用者にとっては、インタフェース側のパッケージは ほぼAPIドキュメントのようなものになりますし、実装が「作りかけ」の 状態でも、利用者側のプログラムのコンパイルまではできるようになったりします。 公式のサーブレットAPI(javax.servlet)も、利用者には(Cookieのような 簡単なクラスを除き)ほぼインタフェースしか公開していないのは、 同じような考え方に基づくものだと私は思っています。 こういう観点でインタフェースと実装のパッケージを分けているわけですが、 そう考えたとき、実装側のパッケージ内でインタフェースの方の型で変数定義 することに、どれほどの意味があるでしょうか。 実装側のパッケージ内では、インタフェースとしては公開していないメソッドや、 publicではないフィールドを参照することもあり得ます。そのたびにダウンキャスト するぐらいなら、最初から実装側のクラスにしておくほうがマシではないかと思います。 servletimplという実装側のパッケージの内部で、むやみに実装隠蔽しようとしても あまり意味はないかと思います。Javaのアクセス制御が、publicもprivateも つけないデフォルト状態で、(C++やC#と違って)パッケージ内公開になっている、 というポリシーも、「パッケージ内での実装隠蔽はあまり意味がない」という 考えに基づくものではないでしょうか。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2105] リストA-13の ”~Impl” について
投稿者:くまきち
2018/02/18 09:44:47

『基礎からのWebアプリケーション開発入門』のP.267にあるリストA-13について質問させてください。 17行目や19行目の変数定義で”HttpSessionImpl”や”HttpServletResponseImpl”などスーパークラスではなくサブクラスの変数定義をしています。 せっかく抽象型を用意しているのであれば、ここは抽象型の変数定義にするのではと思ったのですが、サブクラスの変数定義を使用している理由があれば、教えて頂きたいです。 よろしくお願いいたします。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2104] Re:リストA-13について
投稿者:(ぱ)こと管理人
2018/02/03 22:12:52

>61行目について >誤:data[0] >正:data[i] ご指摘ありがとうございます。 確認しましたが、ご指摘の通りのバグですね。複数件のケースのテストを 怠っていたようです。 正誤表に載せておきます。ありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2103] リストA-13について
投稿者:くまきち
2018/02/02 07:30:59

『基礎からのWebアプリケーション開発入門』のP.267にあるリストA-13について質問させてください。 ちゃんと理解できていないかもしれないですが、もしかすると下記の誤りではないでしょうか? 61行目について 誤:data[0] 正:data[i] ご確認、よろしくお願いいたします。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2102] Re:第7章のTIPSについて
投稿者:くまきち
2018/01/23 23:36:21

確かに。。 >http://localhost:8080/generatecsv/test.html のように指定すればダウンロードできました。 お騒がせしました! >>ただ、CSVダウンロードだけは、まさに >>>C:\Tomcat8\webapps\generatecsv\test.html >>に置いていたのですがダウンロードできませんでした。。 >>HTTPから指定するのが正式だと思うので、とりあえず気にしないことにしました! > >念のため確認ですが、test.htmlをそこに置いたというのはよいとして、 >参照はどのようにしましたか? > >http://localhost:8080/generatecsv/test.html > >として参照すればダウンロードできると思うのですが、 >もし、HTMLファイルをダブルクリックして開いていたらできませんので、 >一応確認です…… >
[この投稿を含むスレッドを表示] [この投稿を削除]
[2101] Re:第7章のTIPSについて
投稿者:(ぱ)こと管理人
2018/01/18 00:41:05

>ただ、CSVダウンロードだけは、まさに >>C:\Tomcat8\webapps\generatecsv\test.html >に置いていたのですがダウンロードできませんでした。。 >HTTPから指定するのが正式だと思うので、とりあえず気にしないことにしました! 念のため確認ですが、test.htmlをそこに置いたというのはよいとして、 参照はどのようにしましたか? http://localhost:8080/generatecsv/test.html として参照すればダウンロードできると思うのですが、 もし、HTMLファイルをダブルクリックして開いていたらできませんので、 一応確認です……
[この投稿を含むスレッドを表示] [この投稿を削除]
[2100] Re:第7章のTIPSについて
投稿者:くまきち
2018/01/14 06:38:59

ご回答頂き、ありがとうございました。 ただ、CSVダウンロードだけは、まさに >C:\Tomcat8\webapps\generatecsv\test.html に置いていたのですがダウンロードできませんでした。。 HTTPから指定するのが正式だと思うので、とりあえず気にしないことにしました! >>>out.print((char)(ch & 0xffff)); >> >>"& 0xffff"は何をしているのでしょうか?不要な制御情報を削除するなどの >>用途があるのでしょうか? > >ここではint型のchをcharにキャストしているので、結果がcharの >範囲に収まるよう、0xffffとの&を取っています。 >まあ、この場合、直前のif文で負でない保証がされていますし、 >InputStreamReader#read()の戻り値なので、あまり気にする必要は >ないのかもしれませんが。 > >>P.241 リスト7-3 36行目 >>dataOutを多次元配列として定義している理由がよく分かりませんでした。 >>一次元配列でも参照型変数となるので、呼び出され側で値を詰めることができるように >>思います。 > >1次元配列を上位でnewして渡し、呼び出され側で値を詰めてもらう、 >ということはできますが、その場合、newするには呼び出し側でサイズが >わかっている必要があります。ここでは、呼び出し側ではサイズがわからないので、 >呼び出され側でnewした配列を参照型変数に格納して返すには、 >配列の配列(2次元配列)が必要になります。 > >>とありますが、例えばP.226の補足に記載されているような最新投稿を表示する >>ようなパーツが、 >>仮にテキストなどでは無く画像で最新記事を返す形式だったら、 >>XMLHttpRequestとか同一オリジンポリシーなど >>考えなくても良いということでしょうか? > >そうなりますね。(JSONPだってその意味では抜け穴ですが) >現状、例えば怪しいサイトのHTMLが社内イントラの画像をimgタグで抜き取ったとして、 >それを怪しいサーバに送ろうとするとHTML5のCanvasを使わなければならず(たぶん)、 >そちらでは別のオリジンから持ってきた画像はデータ化したりできないようにする等 >対策はされていると思いますけれども。 > >>P.248 注3 >>csvダウンロードできませんでした。リンクを、 >> >>><a href="/generatecsv/GenerateCSV">CSVダウンロード</a> > >HTMLファイルはどこに置きましたか? >ここでは、 >C:\Tomcat8\webapps\generatecsv\test.html >のような場所に置いてあることを想定しています。 > >実際にアプリケーションを開発する際も、HTMLなりJSPなりを >GenerateCSVと同じTomcatでホストしていれば、/generatecsv/GenerateCSVで >見えると思います。 > >>P.249 リスト7-8 5行目 >>下記が誤りのように思います。 >> 誤:"http://localhost/downloadtest/file.mp4; >> 正:"http://localhost/downloadtest/file.mp4"; > >申し訳ありません。これは間違いですね。 >正誤表に載せておきます。 >
[この投稿を含むスレッドを表示] [この投稿を削除]
[2099] Re:第7章のTIPSについて
投稿者:(ぱ)こと管理人
2018/01/11 00:14:06

>>out.print((char)(ch & 0xffff)); > >"& 0xffff"は何をしているのでしょうか?不要な制御情報を削除するなどの >用途があるのでしょうか? ここではint型のchをcharにキャストしているので、結果がcharの 範囲に収まるよう、0xffffとの&を取っています。 まあ、この場合、直前のif文で負でない保証がされていますし、 InputStreamReader#read()の戻り値なので、あまり気にする必要は ないのかもしれませんが。 >P.241 リスト7-3 36行目 >dataOutを多次元配列として定義している理由がよく分かりませんでした。 >一次元配列でも参照型変数となるので、呼び出され側で値を詰めることができるように >思います。 1次元配列を上位でnewして渡し、呼び出され側で値を詰めてもらう、 ということはできますが、その場合、newするには呼び出し側でサイズが わかっている必要があります。ここでは、呼び出し側ではサイズがわからないので、 呼び出され側でnewした配列を参照型変数に格納して返すには、 配列の配列(2次元配列)が必要になります。 >とありますが、例えばP.226の補足に記載されているような最新投稿を表示する >ようなパーツが、 >仮にテキストなどでは無く画像で最新記事を返す形式だったら、 >XMLHttpRequestとか同一オリジンポリシーなど >考えなくても良いということでしょうか? そうなりますね。(JSONPだってその意味では抜け穴ですが) 現状、例えば怪しいサイトのHTMLが社内イントラの画像をimgタグで抜き取ったとして、 それを怪しいサーバに送ろうとするとHTML5のCanvasを使わなければならず(たぶん)、 そちらでは別のオリジンから持ってきた画像はデータ化したりできないようにする等 対策はされていると思いますけれども。 >P.248 注3 >csvダウンロードできませんでした。リンクを、 > >><a href="/generatecsv/GenerateCSV">CSVダウンロード</a> HTMLファイルはどこに置きましたか? ここでは、 C:\Tomcat8\webapps\generatecsv\test.html のような場所に置いてあることを想定しています。 実際にアプリケーションを開発する際も、HTMLなりJSPなりを GenerateCSVと同じTomcatでホストしていれば、/generatecsv/GenerateCSVで 見えると思います。 >P.249 リスト7-8 5行目 >下記が誤りのように思います。 > 誤:"http://localhost/downloadtest/file.mp4; > 正:"http://localhost/downloadtest/file.mp4"; 申し訳ありません。これは間違いですね。 正誤表に載せておきます。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2098] 第7章のTIPSについて
投稿者:くまきち
2018/01/10 22:11:30

『基礎からのWebアプリケーション開発入門』のP.235からのTipsについて質問させてください。 P.238 リスト7-1 25行目 >out.print((char)(ch & 0xffff)); "& 0xffff"は何をしているのでしょうか?不要な制御情報を削除するなどの用途があるのでしょうか? P.241 リスト7-3 36行目 dataOutを多次元配列として定義している理由がよく分かりませんでした。 一次元配列でも参照型変数となるので、呼び出され側で値を詰めることができるように思います。 P.245 7.3 画像を動的に生成する ><img src="http://localhost:8080/generateimage/GenerateImage"/> ><image>タグは、それが記載されているHTMLとはまったく無関係のドメインからでも・・・」 とありますが、例えばP.226の補足に記載されているような最新投稿を表示するようなパーツが、 仮にテキストなどでは無く画像で最新記事を返す形式だったら、XMLHttpRequestとか同一オリジンポリシーなど 考えなくても良いということでしょうか? なんとなく、いろいろセキュリティ対策しているけど、抜け道はいろいろありそうな気がしてしまいます。 P.248 注3 csvダウンロードできませんでした。リンクを、 ><a href="/generatecsv/GenerateCSV">CSVダウンロード</a> とすると失敗しましたが、下記のようにすると成功しました(IE、Crome、Firefoxで実施)。 ><a href="http://localhost:8080/generatecsv/GenerateCSV">CSVダウンロード</a> P.249 リスト7-8 5行目 下記が誤りのように思います。  誤:"http://localhost/downloadtest/file.mp4;  正:"http://localhost/downloadtest/file.mp4";
[この投稿を含むスレッドを表示] [この投稿を削除]
[2097] Re:JSONPについて
投稿者:(ぱ)こと管理人
2018/01/06 21:26:56

>・P.226 補足 JSONP① >「JSONPの基本的な原理は ~ <script>タグによるJavaScriptの取得は >同一オリジンポリシーに縛られない」という記載があります。 >ここの意図は、「”外部ファイルからのJavaScript取得”は同一オリジンポリシーに >縛られない」で合っていますか? 合っています。外部ファイルからのJavaScript取得には<script>タグを 使うので、そのように書いています。(確かに、HTML中にJavaScriptを 書く時も<script>タグは使いますけれども) >・P.227 補足 JSONP② >「このようにして関数呼び出しを含むJavaScriptを取り込めば、その関数 >(上記で言えばcallbackFunc)が呼び出されます。」という部分で、 >具体的にcallbackFuncが実行されるタイミングがよく分かりませんでした。 JavaScriptの実行タイミングについてはp.218に書きましたが、 <script>タグで外部のJavaScriptを読み込んだ場合、その<script>タグのある 位置で実行されます。 JSONPの場合、その外部JavaScriptからcallbackFuncを呼び出すわけですから、 callbackFuncもそのタイミングで実行されます。 そのため、HTML上では、外部JavaScriptを読み込む<script>タグは、 callbackFuncの定義より後ろにある必要があります。 >網掛け部分にある「callbackFunc」には、なぜコールバック関数という >名前が付いているのでしょうか。webで調べたコールバック関数は >「他の関数に引数として渡す関数」というイメージなので、ここでこの名前 >(callbackFunc)を使う意図がシックリ来ませんでした。 コールバック関数というのは、その名の通り「呼び返される」関数です。 電話をかけて相手がいないときに「コールバックお願いします」と留守電に 残しておくのと同じように、後で別の人から「呼び返してもらう」関数のことを コールバック関数と呼びます。その手段のひとつして、関数を、 他の関数に引数として渡しておいて後で呼び返してもらう、という方法もあるわけです。 JSONPの場合、<script>タグで取り込んだ外部スクリプトから「呼び返してもらう」 関数なので、コールバック関数と呼んでいます。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2096] JSONPについて
投稿者:くまきち
2018/01/05 21:33:49

立て続けに申し訳ございません。 『基礎からのWebアプリケーション開発入門』のP.226「補足 JSONP」について、3点質問させて頂きたいです。 ・P.226 補足 JSONP① 「JSONPの基本的な原理は ~ <script>タグによるJavaScriptの取得は同一オリジンポリシーに縛られない」という記載があります。 ここの意図は、「”外部ファイルからのJavaScript取得”は同一オリジンポリシーに縛られない」で合っていますか? 「<script>タグによるJavaScriptの取得」という言い方の理解が不安だった為、質問しました。 ・P.227 補足 JSONP② 「このようにして関数呼び出しを含むJavaScriptを取り込めば、その関数(上記で言えばcallbackFunc)が呼び出されます。」という部分で、 具体的にcallbackFuncが実行されるタイミングがよく分かりませんでした。 下記のように考えておけば良いのでしょうか? HTML────────────────────────┐ │ : │ │ <script src="外部サーバのURL"> │ │ : │ └─────────────────────────┘           + 外部サーバのURL(読み込まれる) ──────────┐ │JSONPの編集と下記のJavaScript生成 │  │・callbackFuncの定義(具体的な表示の編集) │ │・callbackFuncの実行(P.226の網掛け部分) │ └─────────────────────────┘           ↓ HTML────────────────────────┐ │ : │ │┌─────────────────────┐ │ ││・callbackFuncの定義(具体的な表示の編集)│ │ ││★callbackFuncの実行(P.226の網掛け部分) │ │ │└─────────────────────┘ │ │ : │ └─────────────────────────┘ ★が読み込まれたときにcallBackFuncが実行される。 ・P.226 補足 JSONP③ 網掛け部分にある「callbackFunc」には、なぜコールバック関数という名前が付いているのでしょうか。webで調べたコールバック関数は「他の関数に引数として渡す関数」というイメージなので、ここでこの名前(callbackFunc)を使う意図がシックリ来ませんでした。 以上、よろしくお願いいたします。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2095] Re:同一オリジンポリシーについて
投稿者:くまきち
2018/01/05 21:19:47

なるほど、そういうことですね。 私は勝手に「社内イントラネットのPC=社内イントラネットのサーバ」と考えてしまっていました! 理解することが出来ました。いつも、ありがとうございます。 >>ご指摘のあった続き部分にある「JavaScriptでXMLHttpRequestを使って >>イントラネットの情報にアクセスし・・・」ですが、このときJavaScriptは >>社内イントラネットのPCにダウンロードされてきているものと思います。 > >そうです。 > >>XMLHttpRequestはサーバとの通信を行うものだと思うので、この場合には >>当てはまらないのではないかと思いました(通信の必要は無いのではないか)。 >>確かにJavaScriptのダウンロード元(怪しいページ)と通信先(イントラ)は >>同一オリジンポリシーに反するので、アクセスできないということは分かりましたが、 >>わざわざそのようなことをする事があるのかな?という所に疑問が残ります。 > >その、怪しいサイトからダウンロードしたJavaScriptが、 >XMLHttpRequestを使って社内イントラネットにアクセスして >情報を盗み出す、という危険があるわけです。 > >①昼休みに社員がPCから怪しいサイトにアクセス >②怪しいサイトから、社員のPCに、悪意を持ったJavaScriptがダウンロードされる >③悪意を持ったJavaScriptが、XMLHttpRequest等を使って社内イントラの > 情報にアクセスする。 >④悪意を持ったJavaScriptは、盗んだ情報を、XMLHttpRequestなりPOSTなりで > 怪しいサイトに送信する。 > >もちろんそのためには社内イントラネットの情報源のURLが >わからないといけませんが、それは普通機密情報とみなされないでしょうから >わかっているかもしれませんし、ありがちなグループウェアのURLを >しらみつぶしにするとかも考えられるのではないでしょうか。 > >
[この投稿を含むスレッドを表示] [この投稿を削除]
[2094] ファイル名のみで実行できました!
投稿者:huieders
2018/01/05 20:29:05

早速のご返答ありがとうございます。 Eclipseで作っていたのですが、WebAppというプロジェクトの中にjp.sampleパッケージを作り、そのパッケージの中に各javaとテキストを入れていました。 /WebApp/src/jp/sample/TcpClient.java という格好です。 >たとえばTcpServer.javaのプログラムをTcpServerという名前のプロジェクトで >作ったのだとすると、server_send.txtは > >C:\…\<ワークスペース>\TcpServer\server_send.txt > >という位置に配置する必要があります。 ご指摘のようにプロジェクト直下にテキストファイルを移動したところ、 ファイル名のみで実行でき、recvテキスト二つも作成できました。 パス省略時はどこを探すのかも知らず、お手数おかけし申し訳ございません。 丁寧に説明くださり、大変助かりました。 続きに取り組んでまいります。どうもありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2093] Re:リスト1-1,1-2の各txtのパスについて
投稿者:(ぱ)こと管理人
2018/01/05 15:59:13

はじめまして。 >書籍のとおりソースを書いて実行したところ FileNotFoundException となりました。 クラスファイルはどこにあって、どのように実行していますか? JavaのFileInputStreamでは、フルパスでなくファイル名だけ指定した時、 実行時のカレントディレクトリからファイルを探します。なので、 >TcpServer.java、TcpClient.java、server_send.text、client_send.txt >ファイルはすべて同じフォルダ内に作っています。 という状態で、コマンドプロンプトから C:\Users\誰それ\…\該当フォルダ> javac *.java のようにコンパイルして(するとその場に.classファイルができるはず) C:\Users\誰それ\…\該当フォルダ> java TcpServer と実行すれば、「C:\Users\誰それ\…\該当フォルダ」内のserver_send.txtを 開くことができるはずです。 コマンドプロンプトでコンパイル/実行しているのではなく、 たとえばEclipseで開発しているのだとすると、Eclipseで実行した際の カレントディレクトリはプロジェクトのディレクトリになるので、 たとえばTcpServer.javaのプログラムをTcpServerという名前のプロジェクトで 作ったのだとすると、server_send.txtは C:\…\<ワークスペース>\TcpServer\server_send.txt という位置に配置する必要があります。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2092] リスト1-1,1-2の各txtのパスについて
投稿者:huieders
2018/01/04 22:23:56

はじめまして。初版 第1刷のp.15、p.16にあるTcpServer.javaとTcpClient.javaについて質問です。 FileOutputStream、FileInputStreamの引数を書籍のとおりファイル名のみにすると FileNotFoundException になってしまうのですが、なにか手順を飛ばしてしまっているのでしょうか? 【状況】 TcpServer.javaの7・8行目およびTcpClient.javaの7・8行目において、 引数が("server_send.txt")などになっている箇所がございますが、 書籍のとおりソースを書いて実行したところ FileNotFoundException となりました。 TcpServer.java、TcpClient.java、server_send.text、client_send.txtファイルはすべて同じフォルダ内に作っています。 【対処】 ソースの("○○.txt")の部分を、ファイル名だけではなく("C:\\Users\\(省略)\\client_send.txt")という風にパスまで含めたものに記述しなおしたところ、書籍の記載どおり   クライアントからの接続を待ちます。[ここで一旦停止]   クライアント接続   通信を終了しました の手順まで進めることができ、resvファイルもそれぞれ生成できました。 【質問】 書籍p.17の「サーバ側とクライアント側にそれぞれserver_send.txtとclient_send.txtを用意したうえで」とは具体的にどうすればよいのでしょうか? 「対処」で自分がやったようにソースコード上で毎回パスまですべて記述するというのは違和感があるのですが、書籍のようにファイル名のみの指定でうまく動作させる方法が分かりません。 どうかご教示いただけますと幸いですが、 本書で想定している対象読者のレベル以前の質問でしたら申し訳ございません。勉強しなおしてまいります。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2091] Re:同一オリジンポリシーについて
投稿者:(ぱ)こと管理人
2018/01/04 15:47:13

>ご指摘のあった続き部分にある「JavaScriptでXMLHttpRequestを使って >イントラネットの情報にアクセスし・・・」ですが、このときJavaScriptは >社内イントラネットのPCにダウンロードされてきているものと思います。 そうです。 >XMLHttpRequestはサーバとの通信を行うものだと思うので、この場合には >当てはまらないのではないかと思いました(通信の必要は無いのではないか)。 >確かにJavaScriptのダウンロード元(怪しいページ)と通信先(イントラ)は >同一オリジンポリシーに反するので、アクセスできないということは分かりましたが、 >わざわざそのようなことをする事があるのかな?という所に疑問が残ります。 その、怪しいサイトからダウンロードしたJavaScriptが、 XMLHttpRequestを使って社内イントラネットにアクセスして 情報を盗み出す、という危険があるわけです。 ①昼休みに社員がPCから怪しいサイトにアクセス ②怪しいサイトから、社員のPCに、悪意を持ったJavaScriptがダウンロードされる ③悪意を持ったJavaScriptが、XMLHttpRequest等を使って社内イントラの  情報にアクセスする。 ④悪意を持ったJavaScriptは、盗んだ情報を、XMLHttpRequestなりPOSTなりで  怪しいサイトに送信する。 もちろんそのためには社内イントラネットの情報源のURLが わからないといけませんが、それは普通機密情報とみなされないでしょうから わかっているかもしれませんし、ありがちなグループウェアのURLを しらみつぶしにするとかも考えられるのではないでしょうか。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2090] Re:同一オリジンポリシーについて
投稿者:くまきち
2018/01/03 21:17:15

回答ありがとうございます。ですが、もう少しだけ分からないため、再質問させて下さい。 ご指摘のあった続き部分にある「JavaScriptでXMLHttpRequestを使ってイントラネットの情報にアクセスし・・・」ですが、このときJavaScriptは社内イントラネットのPCにダウンロードされてきているものと思います。XMLHttpRequestはサーバとの通信を行うものだと思うので、この場合には当てはまらないのではないかと思いました(通信の必要は無いのではないか)。 確かにJavaScriptのダウンロード元(怪しいページ)と通信先(イントラ)は同一オリジンポリシーに反するので、アクセスできないということは分かりましたが、わざわざそのようなことをする事があるのかな?という所に疑問が残ります。 正月早々、申し訳ありませんが、お時間があるときに回答頂けると助かりますww >>「会社で昼休みに・・・」という例が挙がっていますが、この場合、自分から >>怪しいwebページにアクセスしているので、javascriptのダウンロード元と >>通信先が同一になってしまうように思います。つまり、同一オリジンポリシーは >>満たしていると思われるため、この例の意図が分からず質問させて頂いたものです。 > >怪しいページについてはその通りですが、続きに以下のように書いています。 > >>怪しいページにて、JavaScriptでXMLHttpRequestを使ってイントラネットの >>情報にアクセスし、それをXMLHttpRequestなりフォームのPOSTなりで >>外部サーバに送信すれば情報が盗めてしまう、というのでは困ります。 > >つまり、この文脈で、同一オリジンポリシーにひっかかってアクセスできないのは、 >社内イントラネットの情報の方です。 >
[この投稿を含むスレッドを表示] [この投稿を削除]
[2089] Re:同一オリジンポリシーについて
投稿者:(ぱ)こと管理人
2018/01/03 10:13:49

>「会社で昼休みに・・・」という例が挙がっていますが、この場合、自分から >怪しいwebページにアクセスしているので、javascriptのダウンロード元と >通信先が同一になってしまうように思います。つまり、同一オリジンポリシーは >満たしていると思われるため、この例の意図が分からず質問させて頂いたものです。 怪しいページについてはその通りですが、続きに以下のように書いています。 >怪しいページにて、JavaScriptでXMLHttpRequestを使ってイントラネットの >情報にアクセスし、それをXMLHttpRequestなりフォームのPOSTなりで >外部サーバに送信すれば情報が盗めてしまう、というのでは困ります。 つまり、この文脈で、同一オリジンポリシーにひっかかってアクセスできないのは、 社内イントラネットの情報の方です。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2088] 同一オリジンポリシーについて
投稿者:くまきち
2018/01/03 01:34:01

『基礎からのWebアプリケーション開発入門』のP.225にある同一オリジンポリシーについて、解説にある例が分からず質問させてください。 「会社で昼休みに・・・」という例が挙がっていますが、この場合、自分から怪しいwebページにアクセスしているので、javascriptのダウンロード元と通信先が同一になってしまうように思います。つまり、同一オリジンポリシーは満たしていると思われるため、この例の意図が分からず質問させて頂いたものです。 初歩的な質問かも知れませんが、よろしくお願いいたします。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2087] Re:リスト6-11について
投稿者:(ぱ)こと管理人
2017/12/31 16:25:14

>51行目 >誤:<thead> >正:</thead> ご指摘ありがとうございます。ポカが多く申し訳ありません。 正誤表に追加しました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2086] リスト6-11について
投稿者:くまきち
2017/12/31 00:45:55

『基礎からのWebアプリケーション開発入門』のP.219にあるリスト6-11について、非常にささいではありますが誤植かなと思ったところがあったので、念の為、連絡しておきます。 51行目 誤:<thead> 正:</thead>
[この投稿を含むスレッドを表示] [この投稿を削除]
[2085] Re:6.5 認証 について
投稿者:(ぱ)こと管理人
2017/12/30 17:59:56

>P.199 >6.5節の認証はクライアント側の認証、6.4.1節②の認証はサーバ側の認証の話、 >という理解で合っていますでしょうか? まあそうですが、クライアント側、サーバ側というと意味が不明確かと。 ・6.5節の認証は、ログインしているユーザが正しいユーザであることを  確認するための認証 ・6.4.1節②の認証は、通信相手のサーバが正しいサーバであることを  確認するための認証 です。 >P.204 >レルムはパスワードファイル作成時(htdigest)にも指定し、「.htaccess」にも >指定しています。これらの整合性は、どのように扱われるのでしょうか? 同じものを2か所に書いているから整合性が心配だということだと思いますが、 p.204に「これはつまり、複数のレルムのユーザを、1つのパスワードファイルで 管理できることを意味しています」とあるように、レルムをキーに どの領域のユーザかを識別しているわけです(いかにも表示用の文字列を キーにするのが気持ち悪いというのは同意します)。 >P.205 >ncは何をカウントしているのでしょうか?同じノンスに対するレスポンスの >送信回数が2回以上という状況が想像できませんでした。 リプレイ攻撃の防止用です。通信経路が盗聴されている時、正当な利用者が 投げた認証情報とまったく同じ情報を攻撃者が投げると認証が通ってしまう、 という事態を防止するためのものです。 >P.208 >「フォーム認証では~SSL(TLS)を使用しなければ~」とありますが、 >tomcatのフォーム認証は暗号化されているのでしょうか?それとも別途、 >暗号化が必要なものなのでしょうか? リスト6-5のlogin.htmlを見ればわかるようにただのform要素なので、 暗号化はされません。別途TLSを使用する必要があります。 >P.211 >④の後のShowBBSを表示するリクエストとレスポンスで、JSESSIONIDの値が違いました。 >これは、なぜでしょうか?セッションIDの固定化(Session Fixation)攻撃と >関係あるのでしょうか。 関係あります。このページの説明がわかりやすいかと思います。 http://bakera.jp/glossary/%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E5%9B%BA%E5%AE%9A%E6%94%BB%E6%92%83
[この投稿を含むスレッドを表示] [この投稿を削除]
[2084] 6.5 認証 について
投稿者:くまきち
2017/12/29 23:49:01

『基礎からのWebアプリケーション開発入門』のP.199からの認証について何点か質問させてください。 P.199 6.5節の認証はクライアント側の認証、6.4.1節②の認証はサーバ側の認証の話、という理解で合っていますでしょうか? P.204 レルムはパスワードファイル作成時(htdigest)にも指定し、「.htaccess」にも指定しています。これらの整合性は、どのように扱われるのでしょうか? P.205 ncは何をカウントしているのでしょうか?同じノンスに対するレスポンスの送信回数が2回以上という状況が想像できませんでした。 P.208 「フォーム認証では~SSL(TLS)を使用しなければ~」とありますが、tomcatのフォーム認証は暗号化されているのでしょうか?それとも別途、暗号化が必要なものなのでしょうか? P.211 ④の後のShowBBSを表示するリクエストとレスポンスで、JSESSIONIDの値が違いました。これは、なぜでしょうか?セッションIDの固定化(Session Fixation)攻撃と関係あるのでしょうか。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2083] Re:セッションの補足について
投稿者:(ぱ)こと管理人
2017/12/26 00:07:18

>①Webサーバがたくさんある場合 >「アプリケーションサーバソフトウェア(Tomcatなど)が再起動した場合には、 >セッションが失われてしまいます」とありますが、それはなぜでしょうか? >アプリケーションサーバソフトウェアを再起動すると、その上で動くサーブレットも >再起動となりセッションもクリアされるからでしょうか。その意味では、 >Webサーバがたくさんある場合とは直接関係ないものでしょうか? 確かに、Webサーバが1台でも「Webサーバが壊れたとか、アプリケーションサーバ ソフトウェア(Tomcatなど)が再起動した場合には、セッションが失われてしま」う ことに変わりはないですね。 意図としては、Webサーバがたくさんある場合、普通は「1台くらい壊れても 問題なく動作する」ことを期待して「冗長化」するのであって、にもかかわらず (そのサーバに接続していたユーザだけとはいえ)セッションが失われてしまうのでは Webサーバをたくさんにした意味がない、という趣旨で書いています。 >②セッションをCookie以外で実現する方法 >「URL Writing」の説明に「RefererなどでセッションIDが漏洩しやすい」とありますが、 >それはなぜでしょうか?CookieならばJavascriptから見えないようにすることが >できるからでしょうか? CookieならJavaScriptから見えないようにできるというのもありますが、 この文章での意図としては、書いてある通り「RefererなどでセッションIDが漏洩」すると いうことです。SNSなどで、悪意を持ったユーザが自サーバのURLを貼ったら、 そのサーバのアクセスログのRefererのところに、うっかりリンクを踏んだ人の セッションIDが普通に現れます。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2082] セッションの補足について
投稿者:くまきち
2017/12/25 01:02:42

『基礎からのWebアプリケーション開発入門』のP.163、164の補足について質問させてください。 ①Webサーバがたくさんある場合 「アプリケーションサーバソフトウェア(Tomcatなど)が再起動した場合には、セッションが失われてしまいます」とありますが、それはなぜでしょうか? アプリケーションサーバソフトウェアを再起動すると、その上で動くサーブレットも再起動となりセッションもクリアされるからでしょうか。その意味では、Webサーバがたくさんある場合とは直接関係ないものでしょうか? ②セッションをCookie以外で実現する方法 「URL Writing」の説明に「RefererなどでセッションIDが漏洩しやすい」とありますが、それはなぜでしょうか?CookieならばJavascriptから見えないようにすることができるからでしょうか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[2081] Re:【C言語ポインタ完全制覇】3-1-2 Cの宣言を解読する
投稿者:(ぱ)こと管理人
2017/12/23 23:26:00

>というわけで、プログラム出力は兎も角として、解説の文章では(第2版でも仰っている >ように)必要な冠詞を抜かさず英語としてまともな文章になさるほうが良いと、僕は >思います。 本来の英語としてはそうだろうと思います(intの前とかは微妙な気もしますが)。 本書内のは、まあ、説明用の英語もどきということでご理解ください。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2080] Re:【C言語ポインタ完全制覇】3-1-2 Cの宣言を解読する
投稿者:knwifuru
2017/12/22 09:15:25

>># あ、本の中の英語の文章ですが、可算名詞に冠詞が抜けているものが少なからず >>ありました… > >これはK&Rのdclもそうなっているからいいだろう、ということで付けていません。 >第2版では、p.163に注の形で言い訳を入れました。 >(韓国語版では、訳者の方が足してくれたりしたようですが) ># この注で、「declでも付けていませんし」とあるのはdclの間違いですね… ># 後ほど正誤表に挙げます。 あ、本当だ! この件に関しては、第2版を確認せずに投稿しちゃってました… (^^; 確かに、K&$第二版日本語版のp149の、dcl『の実行結果』も、冠詞が抜けています。 原著第二版(1988)のp122ページの『実行出力』でも、ありませんね。 また、"Pointers on C" (Kenneth A. Reek, Addison Wesley(1988))のp355で 紹介されている、cdeclというプログラム https://cdecl.org/ https://github.com/ridiculousfish/cdecl-blocks 『の出力』でも、冠詞は省略しているみたいですね。 $ cdecl Type `help' or `?' for help cdecl> explain int(*f)(void); declare f as pointer to function (void) returning int しかし、これは、あくまでプログラム出力を簡潔にするためだと思います。 実際、"C - A Reference Manual (5ed.)"(Harbison & Steel, Prentice Hall (2002))の 4 Declarationsという章の最初のページ(p73)にも Declarations in C are difficult to describe for several reasons. First, they involve some unusual syntax that may be confusing to the novice. For example, the declaration int (*f) (volid); declares a pointer to a function taking no arguments and returning an integer. と、文章ではきちんと冠詞をつけていることからも、英語としては冠詞が必要である ことが明らかですし、K&R原著第二版で配列が最初に説明される 1.6 Arrays (p22)で でだって、本文文章では The declaration int ndigit[10]; declares ndigit to be an array of 10 integers. と書かれています。 というわけで、プログラム出力は兎も角として、解説の文章では(第2版でも仰っている ように)必要な冠詞を抜かさず英語としてまともな文章になさるほうが良いと、僕は 思います。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2079] Re:【C言語ポインタ完全制覇】3-1-2 Cの宣言を解読する
投稿者:(ぱ)こと管理人
2017/12/22 01:20:10

>結局、Cの宣言は、日本語的に考えるとダメで(識別子から遠い側の配列宣言[3]を先に解釈 >しないと正しくない)、英語で表現して考えないとダメだ、ということなんでしょうかね… そうです。 まあ、Cの宣言は英語圏でも「酷評を受ける」そうですが、 日本人にとってはさらにひとつハードルが増えますね。 ># あ、本の中の英語の文章ですが、可算名詞に冠詞が抜けているものが少なからず >ありました… これはK&Rのdclもそうなっているからいいだろう、ということで付けていません。 第2版では、p.163に注の形で言い訳を入れました。 (韓国語版では、訳者の方が足してくれたりしたようですが) # この注で、「declでも付けていませんし」とあるのはdclの間違いですね… # 後ほど正誤表に挙げます。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2078] Re:【C言語ポインタ完全制覇】ポインタはどれだけ進む?
投稿者:(ぱ)こと管理人
2017/12/22 01:07:55

>コンパイラが密かに(いえ、きちんと被参照型のサイズを考えて)計算して正しい >値(アドレス)に置き換えてくれてる、ということなのですかね(でしょうね)? そういうことですね。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2077] 【C言語ポインタ完全制覇】3-1-2 Cの宣言を解読する
投稿者:knwifuru
2017/12/21 10:26:47

バカな質問ばかりして恐縮です。 第1版のp144に『②識別子に近い方から、優先順位に従って派生型(ポインタ、配列、関数)を解釈する。』とあります。 これでいくと、Table 3-1の3番目、 int hoge[10][3]; は、  「識別子"hoge"に一番近いのは、配列[10]。その次が配列[3]。最後に、int」 なので、  「要素数10個の配列が、3つ並んで(また配列を作って)いる。(基本型はint)」 となると思えるのですが、“日本語的表現”では  hoge は、intの配列(要素数3) の配列(要素数10) と、「要素数3の配列が10個並んでいる」という意味とされています。(Fig. 3-15でも同様) 結局、Cの宣言は、日本語的に考えるとダメで(識別子から遠い側の配列宣言[3]を先に解釈しないと正しくない)、英語で表現して考えないとダメだ、ということなんでしょうかね… (質問というか、ぼやき?) "'hoge' is an array (with 10 elements) of an array (with 3 elements) of int." # あ、本の中の英語の文章ですが、可算名詞に冠詞が抜けているものが少なからずありました…
[この投稿を含むスレッドを表示] [この投稿を削除]