携帯サイトのWebプロ� ..
357:nobodyさん
09/07/14 18:30:27
>>356
だれがメールクライアントの話をしてるんだ？
358:nobodyさん
09/07/14 22:49:59
送信さえできれば満足
受け取る側が困ろうと関係ないです
359:nobodyさん
09/07/14 23:28:27
はるか昔からある仕組みで、未だに盛り上がれるレベルに乾杯ｗ
360:nobodyさん
09/07/15 00:12:10
未だに悩むから盛り上がるんだよ。
未だに仕事や恋愛で悩む奴が絶えないようにな。
361:nobodyさん
09/07/16 09:27:25
【携帯】 ドコモ 「好調なiPhoneに対する、１つめの武器だ」…グーグル携帯、日本で発売。「スマートフォン戦争」激化へ★３
ｽﾚﾘﾝｸ(newsplus板)
このスレが終わる頃には携帯端末とか意識しなくてもよくなるんじゃね
362:nobodyさん
09/07/16 10:09:22
スマートフォンってPC感覚でサイト作って良いの？
363:nobodyさん
09/07/16 23:21:02
Windows Mobile用は前から作ってるあるだろ？
364:nobodyさん
09/07/17 22:40:48
>>363
つ>>348
365:nobodyさん
09/07/27 16:25:48
SBのIPアドレスが7月24日付けで２個削除されてたよ。
366:nobodyさん
09/07/27 20:10:38
知ってるわそんくらい
ありがと
367:nobodyさん
09/07/27 21:23:18 PdVKv6k8
>>313-315
糞ﾜﾛﾀwwwwwwwwwwwwwwww
368:nobodyさん
09/07/29 21:40:48
>>365
J-Phneの頃の地域会社毎に有ったサーバーを、２箇所無くして集約したって事かな。
369:nobodyさん
09/08/13 14:03:44
質問です。
URLの最後にセッションIDをつけてログイン情報を保持する仕組みを作ったんですが
この方法だと、たとえばユーザー間で「このサイトみてみろよ」みたいなやりとりがあって
メールなどで閲覧中のURLが人に伝えられた場合、ログイン情報も引き継がれてしまいます。
何か良い対策はないでしょうか？
370:nobodyさん
09/08/13 18:08:29 OVywA48x
sessionをregenerateして機種とか接続元とかvalidateしないとまずくね？
まあそれでも不安は残るが。。
371:nobodyさん
09/08/14 00:01:41
>>369
俺がやっている方法
・セッションに、IPアドレス（または個体識別番号）と日時を記録
・ログイン時にチェックこの時、リファラ元も確認
（機種によってリファラが取得出来ない場合もある）
・一定期間を過ぎたアクセスはログインできない
・セッションだけでは不安なので、DBに情報を残しておく
てなことをしている。これで完璧だとは思わないが、そこそこ有効だと思ってる
372:369
09/08/14 02:23:00
>>370,371
ユーザを特定できるような情報を毎回確認する必要があるってことですね。
（リファラがすべての機種でとれればそれでも良かったんですが、残念）
時間切れ等の実装も含めて試行錯誤してみます。
ありがとうございました。
373:nobodyさん
09/08/14 09:02:51
つーか、携帯うんぬん以前の話だろ。ｗ
374:nobodyさん
09/08/14 13:36:24
携帯でCookieがちゃんと動けば、カジュアルコピーで漏洩してしまうURLに乗せなくて済むのにね
375:nobodyさん
09/08/14 23:38:00
携帯のキャリアはIEやFirefox以上に仕様が異なるからな
どれか統一して欲しいよ。ユーザにとって不利益だ
376:nobodyさん
09/08/15 02:48:18
携帯は全部au規格で統一すりゃいいんだよ
377:nobodyさん
09/08/16 18:43:12
ほんと携帯業界は政治争いが酷すぎるｗ
こりゃガラケーとか言われて、世界に通用しないのもわかるわｗ
378:nobodyさん
09/08/17 06:23:51
>>373は、なんで？
おもいっきり携帯の話だと思うんだが。
379:nobodyさん
09/08/18 19:30:07
>>378
ログイン情報をなんのバリデーションもなしにセッションにいれて引き回すのは携帯以前の問題だろjk
380:nobodyさん
09/08/21 09:09:22
378のようなやつは、プロキシ通されるとえらい騒ぎになるぞｗ
前に接続した人の情報が全部見える！なんてことにｗ
381:nobodyさん
09/08/21 11:37:20
greeの話？
382:nobodyさん
09/08/27 16:20:21 vb6War4u
IDとパスワードでガードしてhttps通信するwebを作ったら、それを上手く見れない
第３世代の機種って結構多いでしょうか？
auのやや旧い機種だと駄目っぽい気がしますが、駄目な機種の情報がドコゾに纏めて
あれば嬉しいですが。
383:nobodyさん
09/08/27 18:28:23 GXwqUg2e
モバイルでexcelファイルをダウンロードさせたいんだけど
以下の状況で困ってるので知恵を貸して！
xlsファイルに直リンすると
softbank(911T)はexcelファイルとしてダウンロード＞表示ができた
au「表示できないファイルです」
docomo(N904i)端末はバイナリがそのまま文字として出力された
あとobjectタグとかもあるっぽいけど
docomoだとダメみたいなので
auとdocomoでのダウンロードのさせかたを教えてほしい
ゆくゆくはoffice系のファイルを全部ダウンロードできるようにしたいけど
とりあえず
httpd.confに
AddType application/vnd.ms-excel .xls
を設定してある
384:nobodyさん
09/08/29 16:28:00
もともとdocomoの端末はセキュリティの為にwebからのダウンロードを厳しく
制限してたら多分ダメポ。MOVAだと画像ファイルすらセーブ出来なかったし。
auはダウンロードにobjectタグを使う規定を正規に用意してるし、ドキュメント
ビューアー搭載機種以降なら、多分大丈夫かと思われ。
SBはその点以前から融通が利いてヨカタ。
385:nobodyさん
09/08/29 17:54:58
ちょっと面白い頁を見つけました。日本通信が対象外なのが残念ですが。
そっかロボットのIPも許可しないと検索エンジンに登録されないわな。
携帯端末以外のIPを制限するhtaccessを簡単生成
URLﾘﾝｸ(www.dspt.net)
386:nobodyさん
09/08/29 19:07:10
SoftBankっていつからHTTP1.1になったの？
ついこの間までHTTP1.0だったと思ってたけど。
387:名無しさん＠そうだ選挙に行こう
09/08/30 17:09:16
1.0って名前ベースのバーチャルドメインが使えないんだっけ？
388:nobodyさん
09/08/31 18:48:49
そろそろ文字コードをUTF-8にしていってもいい？
3G機種ならもうほとんど対応しちゃってるよね
389:nobodyさん
09/09/01 02:27:46
結局、ソフトバンクの3G機種の中で絵文字をShift-JISで投げたときに、
ウェブコード絵文字を投げる機種が存在するのかしないのか、そこんとこはっきりしてくれ。
ネット上を探したが(2ch含む)、Shift_JISバイナリで投げることはあるが、
ウェブコードを投げたという記述は一切見かけなかった。
ソフトバンクのウェブコンテンツ開発ガイド見ても、あくまでウェブコードを投げると書いてあるように見えるし、
シミュレータも投げてるように見える。
投げないという保証はないが、投げる機種は最近は存在しないということでいいんだな？
390:nobodyさん
09/09/01 02:34:03
検索の仕方が悪い
391:nobodyさん
09/09/01 02:38:52
「3G機種の中で」というより、知りたいのは「最近の機種で」でした。
最近とはここ２年の間ぐらいです。
392:nobodyさん
09/09/01 16:16:31
>>388
そうなんだよな～。
最近IDとパスワードでガードするサービスの提供先を探してるのだが、ID＆パスワードの
入力画面がUTF-8になっていさえすれば、旧過ぎる機種以外なら大抵の３G端末ならオケだと
思うのだが、そういうのがハッキリしないところが多い。
勿論、携帯対応を標榜してるところもあるから、そういうところはある程度機種別対応して
る筈なので、３G端末以外でも結構使えそうだけど、怪しくなさそうなところを探すのがメン
ドイ。
とりあえず来年３月でSBの２G端末が消滅するから、それを機会にUTF-8に統一しちゃう、って
のが良いかと。まあMOVAは無視する訳だけど。
393:nobodyさん
09/09/02 17:19:17
そういやアパッチサーバーが出力してる、ID＆パスワードの入力画面って、
普通のPCブラウザだとポップアップみたいな別画面で出るモノしか見た事
がないが、携帯で見るとどうなっちゃうのかね？
394:nobodyさん
09/09/02 17:20:36
普通にポップアップされるよ
ただ、古い携帯だと、ポップアップ出ずに普通にページが表示されなかったっけ？
395:nobodyさん
09/09/02 18:12:19
それってサーバー側の設定次第では？
多分安いレンタルサーバーなんかだとムリポな気が。haccessとかで変更出来たっけ？
396:nobodyさん
09/09/02 18:14:03
レン鯖はわかんね
俺は自鯖あるし
397:nobodyさん
09/09/02 19:01:39
携帯電話に今の航空機並のジャロセンサーが搭載されるって凄い話だな。
ＡＴＲ、回転角速度依存信号が検出できる半導体レーザジャイロチップを開発
URLﾘﾝｸ(it.nikkei.co.jp)
角速度センサチップが実現できれば、ロボット、車、携帯端末等にも搭載することができます。将来的には、
ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）と協調することで、ＧＰＳ信号が届かない
地下街、建物内、ビル街、トンネル等でも航空機のように自律的な位置情報検出を行うことができます。得ら
れた位置情報・姿勢情報を用いて、豊かで便利で安全な情報サービスへの展開が可能となります。
398:nobodyさん
09/09/02 19:21:39
>>394 >>396
古くない携帯ならデフォルトのままでオケだから、あまり話題にならないって事かな。
ググリ方が悪いのかもしれんが、それらに関する情報は殆ど見つからなかったし。
399:nobodyさん
09/09/02 19:33:34
>>394
ブラウザの対応がどうだろうと、認証通んなかったら鯖が401返すだろ
400:nobodyさん
09/09/02 20:24:23
携帯電話専用ホームページの制作方法 ２台目
ｽﾚﾘﾝｸ(hp板)l50
401:nobodyさん
09/09/03 09:24:03
ディズニーモバイルの絵文字の仕様って、ソフトバンクの3Gと同じでしょうか？
絵文字のコード範囲も同じだし、
Shift_JISコンテンツ時に入力した絵文字が飛ぶか飛ばないかは機種依存という認識です。
402:nobodyさん
09/09/03 10:31:46
サイトを見に行くことさえできない人か？
403:nobodyさん
09/09/04 07:57:13
URLﾘﾝｸ(disneymobile.jp)
見つけられないですね。
欲しいのは、Shift_JISバイナリ形式の対応表と文字参照形式(？xXX;)での対応の両方が欲しいです。
404:nobodyさん
09/09/04 17:00:19
>>399
ID&パスワード入力画面の表示は、認証前の話だろ。
>>400
多分入力画面は、JS入りのHTML頁をサーバーが生成＆出力してると思われる
から、作成方法のスレだと的外れだわな。
そういう頁を受信した時、旧い携帯でJS非対応なブラウザだと >>394 の言う様に、
ポップアップ無しな表示になるだけかと思われ。
ただそれがutf-8な文字コードでないと、SBの３G端末で問題になりそうだが。
405:nobodyさん
09/09/04 17:08:28
BASIC認証の話じゃなかったっけ?
406:nobodyさん
09/09/04 17:11:42 4sANafbz
これは？URLﾘﾝｸ(mega-r.com)
407:nobodyさん
09/09/04 17:18:04
>>404
>>393はmod_authの話だと思うんだけど？
408:nobodyさん
09/09/05 16:09:08
良く知らなくてスマソだが、mod_auth の中にID＆パスワード入力画面の元になる
HTMLファイルが有る、って話なのか？
まあ何処かに無ければ出来ない訳だが、これを携帯専用にカスタマイズする事は
このスレでは常識な知識ならスマソ。
409:nobodyさん
09/09/05 16:33:41
>>408
ちげー。
HTTPの規格の中に、BASIC認証・DIGEST認証という仕組みがある。
フォームで認証を行うんじゃなくて、
HTTPヘッダーで認証情報を受け渡しして認証を行っている。
ブラウザがあるHTTPヘッダーを受信すると、
ブラウザ自身が、ダイアログを出してユーザー名とパスワードをユーザーに尋ねる。
htmlで認証画面作るのとは全然違う話。
410:nobodyさん
09/09/05 18:39:30
>>409
DIGEST認証は対応してない端末あるね
411:nobodyさん
09/09/05 20:08:44
こんなスレッドが有ったよ。
ネットワークパスワード入力画面について
URLﾘﾝｸ(otn.oracle.co.jp)
412:nobodyさん
09/09/05 20:38:23
>>411
これってブラウザ組み込みのダイアログを使うんじゃなくて、
htmlで出来たフォームに入力させることでBASIC認証させる
っていう話をしてるんだよね?
PHPのソース見てもどういう原理でやってるのか全然わからん…。
もう年なのかな…。
413:nobodyさん
09/09/05 21:40:28
401を返したら認証ダイアログポップアップをブラウザは行う
BASIC認証とは401を受け取ったブラウザがユーザー名パスワードを素で送信する機構
JavaScriptとか使って、ユーザー名パスワードをリクエストヘッダに入れれば出来るのかな？
んなの動く携帯端末があるのだろうか・・
JavaScriptでリクエストヘッダーの加工できるのかなぁ
414:nobodyさん
09/09/05 22:31:12
XmlHttpRequestならヘッダ追加出来るから、
それでページを取得してDHTMLで書き換えなら出来る…はず!
ブラウザの「戻る」「進む」「アドレスバー」は使わないで下さいと
注意書きしないといけないが。
でも>>411はPHP使ってサーバー側のトリックのみで出来るって
話に見えるんだ…。
415:nobodyさん
09/09/07 19:52:19
>>409
レスサンクス
そっかー、ID＆パスワード入力画面はサーバーじゃなくて、端末のブラウザが出してるのか～。
端末のブラウザがBASIC認証に対応してさえいればモーマンタイな訳ですね。ググッテも情報を
見つけられずにいたので助かりました。
そうなるとあと気になるのは以下の２点くらいかな。認証エリアに置く予定のxhtmlな頁には
当初はともかくエンハンス時に外部リンクを入れる予定なので。
（１）クッキーが使えないブラウザな端末だと、認証エリアから出て戻る時に再度
ID＆パスワードの入力を要求されますか？
（２）認証エリアがSSL通信状態だと、非SSLな外部リンクへジャンプ（＆戻る時も？）
する時に、鬱陶しい警告とかは出ますか？
尚、BASIC認証エリアに置く頁は一般公開はしたくはないが、SSL通信が必要な
程にはまさかの時の被害は無い程度のモノなので、使い勝手が悪くなるなら
止めようと思ってます。
まあ携帯のSSLにはベリサインが一番適用機種が多そうだけど、費用が高いみ
たいだから、その点からもSSLをあまり積極的利用するのは避けたいので。
416:nobodyさん
09/09/08 08:43:51
携帯電話専用ホームページの制作方法 ２台目
ｽﾚﾘﾝｸ(hp板)l50
417:nobodyさん
09/09/09 13:20:01 0xXcvXSC
ドメイン指定してるユーザーにメールを送って拒否された時って
どんなレスポンスが返ってきますか？
418:nobodyさん
09/09/09 16:14:35
設定による
普通は何も返答しないようにしてるはず
返答したらそのアドレスが存在するかしないかスパマーにわかっちゃうから
419:nobodyさん
09/09/09 21:14:35
存在しないとエラーが返ってくるから、その理由はおかしいです
420:nobodyさん
09/09/09 21:30:23
たしかにｗ
421:nobodyさん
09/09/09 22:02:33
ウィッシュ
422:nobodyさん
09/09/10 09:06:29
今の携帯って、存在しないときも無応答じゃね？
423:nobodyさん
09/09/10 09:56:33
３キャリアは無応答だね
いちいち返してたらサーバ死ぬから
424:nobodyさん
09/09/12 07:53:44
レベル低すぎワロタｗｗ
なんだこのスレｗｗｗ
425:nobodyさん
09/09/13 12:13:57
SPFを設定していれば、存在しない場合と拒否された場合の両方でUser unknownが返って来る。
携帯向けにメールを送る場合は、IPの逆引きとSPFを正しく設定するべき。
SPFについてはAuのサイトに説明がある↓
URLﾘﾝｸ(www.au.kddi.com)
426:nobodyさん
09/09/13 12:31:47
docomoの話。
HTTPクエリにguid=ONを付けて、環境変数でiモードIDを取得できるのと似たような方法で、
パケ放題コース加入の有無って取得できないんだろうか。
定額サービスに入っていない人がアクセスしてきたときは、警告文を出すか、
利用を制限したいんだけど。
427:nobodyさん
09/09/13 13:24:17
むり
428:nobodyさん
09/09/13 19:33:46
なんかあるよ
429:426
09/09/13 19:43:54
>>427
やっぱムリだよな。
430:nobodyさん
09/09/14 01:00:34 ffqvT8rV
xxne.jpのフリーメールへの送信がConnection timed outになってるのですが
原因分かる方いますか？
ググったらgmailからも送れないようです
グレイリスティングだったらrejectされたログが残ると思うのですが
smtp接続自体を拒否してるっぽいのが謎です
海外のサーバを一律弾いてるとかでしょうか？
SPFレコードも設定し、携帯の生アドレスには問題なく送信できています
431:nobodyさん
09/09/14 02:23:25
なんかxxne.jpのメアド、捨てアドとしてそこら中に書き込まれてますね
スパイダーにメアド拾われる
→SPAMが大挙
→iptablesでIPレベルの国別フィルタリング
ってことかも
利用者が多いのがいかんともしがたいですなー
432:nobodyさん
09/09/14 02:48:56
国内サーバからtelnetで25に繋ぐ→OK
米国から→NG
だったのでやっぱりそういうことみたいです
433:nobodyさん
09/09/16 13:54:28
>>415
とりあえずクッキーに関しては、３G端末ならdocomo以外はオケな模様。
URLﾘﾝｸ(ueblog.natural-wave.com)
SSL通信もクッキーが利くならモーマンタイって感じか？
URLﾘﾝｸ(blog.mynet.co.jp)
結局これらに関してdocomoはクソって話になるみたいだけど。
434:nobodyさん
09/09/16 17:30:08
auはBASIC認証はブラウザ落とすまでセッションは維持される
ちなみにBASIC認証はクッキー関係ない
435:nobodyさん
09/09/17 03:05:02
auじゃなくても、そもそもBASIC認証ってそういうもんやん
436:nobodyさん
09/09/17 22:00:46
あー実機auしか持ってないから確認してないよって意味ね
437:nobodyさん
09/09/18 16:29:11
じゃあSSL通信はクッキーに関係するの？
438:nobodyさん
09/09/18 16:31:34
なんかあったような気がするなぁ。。。忘れてしまった。
SSLのクッキーしかダメとか
SSLとhttpのを別々に扱うとか、
そんな端末あったような気がする。
439:nobodyさん
09/09/18 16:35:37
CookieのSecureオプションの話?
端末の対応状況は知らんが。
>>437
何が聞きたいのか良く分からんが、
SSLはCookieなくても動くし、
CookieはSSLなくても動作する。
そういう意味では関係が無い。
440:nobodyさん
09/09/18 17:03:55
SSL通信エリアから出たり入ったりする時に、いちいち「安全ですかあ？」みたいな
警告を出すのと関係するのかな？と思ったのですが。
あ、そうそうSBのIPアドレスが本日付けで一個修正されてました。
PCサイトブラウザ用が少し増えただけな様ですが。
以前の修正から２ヶ月経ってないってのに、チマチマ修正しないで欲しい。＞SB
441:nobodyさん
09/09/20 01:22:00 e093Z6PT
携帯用サイトにカレンダー表示するのって
どうやります？
日 月 火 水 木 金 土
20 21 22 23 24 25 26
この横幅が入らない機種に対してどうするかが問題ですよね・・
442:nobodyさん
09/09/20 06:11:13
携帯電話専用ホームページの制作方法 ２台目
ｽﾚﾘﾝｸ(hp板)l50
443:nobodyさん
09/09/21 03:05:11
>>441
いっそのこと、セレクトメニューにするのはどうだ？
長くてめんどくさいけど、横幅は取らないぞ
444:nobodyさん
09/09/21 06:15:12
画像にするが
445:nobodyさん
09/09/21 07:33:20
横幅が入らない機種を非対応にする
446:nobodyさん
09/09/21 09:47:29
日 1 8 15 22 29
月 2 9
火 3 10
水 4
木 5
金 6
土 7
447:nobodyさん
09/09/22 23:41:11
とりあえず文字を小さくする。
でも446の縦型にするってのも良い案だな。fomaでnowrapが使えれば別な手段もあるが。
いずれにしても流石にこの件は442に禿同。
448:nobodyさん
09/09/22 23:48:06
>>440
こんな記事があったよ。
グーグル、クッキーの安全強化のためSSLを変更
URLﾘﾝｸ(japan.cnet.com)
449:nobodyさん
09/09/24 22:28:59 uICqbhvr
>>441
①案、数字や文字を画像に置き換えてテーブル内に置き換えする。
②案、半角スペースを無くして曜日毎色を変えて見やすくする。
このプログラムのポイントはifとタイムスタンプとテーブルですね。
450:nobodyさん
09/09/24 22:45:31
月火水木金土日
01 ・・・・・・
07・・予予・・・
14・・・・・・・
21・休・・・・・
28・・・・
予 予定
休 休み
携帯では絵文字で
451:nobodyさん
09/09/24 22:46:37
googleカレンダーってモバイル表示可能だったっけ？
どうなってるんかな
452:nobodyさん
09/09/25 18:27:29
こちらでどうぞ
携帯電話専用ホームページの制作方法 ２台目
ｽﾚﾘﾝｸ(hp板)l50
453:nobodyさん
09/09/28 07:09:29
googleカレンダーを公開にして携帯で見てみたら
ひじょーにおそまつな画面でした・・
これなら勝てるかも
>>452
カレンダーを静的に表示することなんてまずないんだから
こっちでもいいと思います
454:nobodyさん
09/09/29 02:40:44
携帯のカレンダー機能でダメなんか？
455:nobodyさん
09/09/29 04:03:41
てか、現実的にカレンダーの横幅が入らない機種なんてほとんどないだろｗ
FileMobileSimulatorでN505とかにしても余裕で収まるし
456:nobodyさん
09/09/29 07:06:14
>>453
＞静的に表示することなんてまずないんだから
そんなことないぞｗ
457:nobodyさん
09/09/29 08:53:14
>>456
そうか？
458:nobodyさん
09/09/29 10:15:19
>>455
馬鹿か
459:nobodyさん
09/09/29 10:29:24
>>458
ｷﾃｨｶﾞｲ乙
460:nobodyさん
09/09/29 12:03:57
もじの大きさをかえたりしてるのを考慮できない鈍感が
システム作るから使いづらいものができる
461:nobodyさん
09/09/29 19:09:38
一週間で7マスとして、テーブル組すると、小フォントにしてギリギリかな。Aタグ使うと、カーソル移動がうざくなるだろうな。
462:nobodyさん
09/09/29 19:52:25
tableがつかえるなら二列組で縦表にするな。
---------------------
8(月) | |
---------------------
9(火) | |
---------------------
10(水) | なんかの日 |
---------------------
・
・
・
って
463:nobodyさん
09/09/29 21:36:21
それか、
８｜１｜月
９｜２｜火
10｜３｜水
11｜４｜木
12｜５｜金
13｜６｜土
14｜７｜日
って感じにして、携帯を反時計回りに90度回転して使ってもらうとか。グッドアイディアだな。
464:nobodyさん
09/09/29 23:09:55
こういうのはどうだ？
横幅が入る機種→通常通りカレンダー表示
横幅が狭い機種→縦型に表示
自動で表示を切り分ければいいと思うんだが。ユーザに負担もないし。
465:nobodyさん
09/09/30 02:54:14
ケータイのフォントは等幅だから
テーブルにしなくても文字だけでもいけるだろ
466:nobodyさん
09/10/01 14:40:10 IMhzYK1H
auの携帯サイトを作ろうと思っているのですが、
パケット転送量を減らすため、携帯内にある画像を参照したいと考えています
この場合URLはどう指定したらいいんでしょうか
PCの場合、<img src="file://c:/image.jpg">のような指定ができますが、auの時はどうなりますか？
467:nobodyさん
09/10/01 14:52:46
ググレカスといわざるを得ない
468:age
09/10/01 15:06:57 IMhzYK1H
ググって見つからなかったので聞いています
469:nobodyさん
09/10/01 16:12:16 Q9ytlH8d
多分無理。ブラウザから携帯内のhtmlファイルも見れなくなってるからな。
470:nobodyさん
09/10/02 21:10:55
無知なにんでんで申し訳ないですが・・・質問させてください。
メニューなどを使いまわす場合、
ＰＣサイトではincludeなどで
必要な箇所へ呼び出して表示をしますが携帯ではできるのでしょうか？
そしてキャリアによって対応非対応とかは、ありますか？
ちなみにサーバはロリポップを使っています。
471:nobodyさん
09/10/03 01:05:59
includeって何のこと言ってるんだ?
472:nobodyさん
09/10/03 02:20:57
>>470
もちろん使えるよ
473:nobodyさん
09/10/03 04:00:03
エスパーだけどPHPだろ
474:nobodyさん
09/10/03 04:27:56
そもそもこのスレがここに存在するのは
スレ主がPHPしか使えなかったからです。
475:nobodyさん
09/10/03 04:30:24 Dod/6t2i
iモードIDって、古い機種からも取得できてますか？
2008年3月の提供開始から以降の端末だけではないですよね？
サーバで付加されるわけだから全端末で取得できるとは思うのですが、
ON/OFFのユーザ設定は"以降"の機種だけについてる気もするし、
まとめると結局どう対処していいのか迷う・・・
476:nobodyさん
09/10/03 08:20:50
>>475
まとめ：古い機種は切り捨てる
477:nobodyさん
09/10/04 15:12:57
472>>
使えますか。すみませんありがとう御座います(苦笑
因みにロリポ(PHP5)では一般的？の記述では動かないらしいのですが…
あつかましいの承知しています。
できればロリポで正常な動作する記述を教えていただきたいのですが…？
すいません。お願いいたします。
使いたい形式はthmlファイルをPHPとして扱って動作させるタイプです。
478:nobodyさん
09/10/04 16:20:39
せめて日本語は
479:nobodyさん
09/10/05 19:35:18
auがIPアドレスの１個追加予定（'10年2月）を出したよ。
docomoと同様に事前発表する様になったみたいで喜ばしい。
480:nobodyさん
09/10/07 00:17:26
>>477
ここは見たの？
URLﾘﾝｸ(lolipop.jp)
481:nobodyさん
09/10/07 15:46:44
【裁判】 "モバゲー vs ＧＲＥＥ" 「釣りゲーム、うちのとそっくりだ！」訴訟、ＤｅＮＡ「裁判で正当性証明する」と争う姿勢
ｽﾚﾘﾝｸ(newsplus板)l50
482:nobodyさん
09/10/07 15:52:45
糞VS糞か
483:nobodyさん
09/10/07 16:24:58
グリーってモバイルはてなより
WEBプログラムがダメだと思う。
484:nobodyさん
09/10/07 16:35:12
プログラムって言うより商売が汚い
そこで実際に犯罪が起こってるのにどこが「健全サイト」なんだよ
人と人を疎のまま置いておく2chの方が健全なくらいだろ
485:nobodyさん
09/10/07 16:55:10
>>484
それはスレ違い
486:nobodyさん
09/10/07 17:56:59
ああいう釣りゲームなんて携帯ゲームになる前からいくらでもあるだろ
487:nobodyさん
09/10/07 18:04:12
モバゲーにしてみたら「こっちが先にパクられた」って気持ちがあるだろうな
488:nobodyさん
09/10/07 18:12:24
greeは登録画面が文字化けして
登録が出来ない携帯があるw
489:nobodyさん
09/10/08 09:08:02
GREEはauだけはしっかりチェックしてると思うぞｗ
490:nobodyさん
09/10/09 01:11:21
釣りゲーム作ろうぜ
491:nobodyさん
09/10/10 19:06:47
「無料で遊べる」携帯ゲーム、高額請求トラブル相次ぐ
ｽﾚﾘﾝｸ(newsplus板)l50
とりあえずgree消えて
492:nobodyさん
09/10/10 19:47:43
「無料で遊べる」携帯ゲーム、高額請求トラブル相次ぐ★２
ｽﾚﾘﾝｸ(newsplus板)l50
493:nobodyさん
09/10/10 21:55:57
グリーって以前は他社と比べるとマシな感じだったが
見事にダークサイドに墜ちたよな
ethna作った人とかまだいんの？
恥ずかしくないのかね、技術者として
494:nobodyさん
09/10/11 01:00:12
藤本さん？
役員でいるよ
495:nobodyさん
09/10/11 01:10:07
そういえば最近モバゲは課金システムを提供すると
参加企業を募ってたな。
mixiやらgreeやらで参加者が使ってたり、アップされてる画像を
芸能事務所やらの著作権者がまとめて削除依頼を出せばどうなるだろう。
しかし、フィルタリングやらホントに迷惑な話だ。
496:nobodyさん
09/10/11 11:04:13
【社会】「無料で遊べる」携帯ゲーム、高額請求トラブル相次ぐ★４
ｽﾚﾘﾝｸ(newsplus板)l50
497:nobodyさん
09/10/13 13:16:13
phpからPEARのMail.phpを使用してWeb上から
ソフトバンクのケータイに日本語のメールを送信すると
文字化け？してるのかわかりませんが日本語の部分が表示されません。
ソフトバンクのケータイはutf-8じゃないといけないとどっかのサイトで見つけたので
mb_language("ja");
mb_internal_encoding("UTF-8");
mb_convert_encoding($Message,"UTF-8","auto");
のように変換を行ったのですが、うまく変換されてないのか成功しません。
変換ができてないのか、それとも文字コードの指定事態が間違ってるかすらも検討がつかなくて
どーすればいいかわからない状況です。
498:nobodyさん
09/10/13 15:03:50
でっていう
499:nobodyさん
09/10/13 15:48:49
肝心の送信部分のソースもなしでは、どうにもこうにも判断できません。
500:nobodyさん
09/10/13 23:19:50
885:名無しさん＠十周年 :2009/10/12(月) 04:52:42 ID:yrcFiKDA0
この件で気の毒なのはモバゲーだろ。
モバゲーはＳＢが認証ないのを知っていて、1枚確認画面挟んでいる。
それをグリーはやってない。
グリー側の責任も大きい。
GREEはヘボいですな。
皆さんも気をつけましょうね。
501:nobodyさん
09/10/14 03:27:09
公式サイトの運営実績少ないからそう言うところでサービスに差が出るんだろうな
502:nobodyさん
09/10/14 04:08:04
greeはwebプログラムとしては三流だと思う
503:nobodyさん
09/10/14 04:20:54
いいのはフレームワークだけだからな
504:nobodyさん
09/10/14 04:35:30
GREEのセッションやべぇ
505:nobodyさん
09/10/14 09:41:25
フレームワークも悪くはないが
せいぜい二流だな
センスは嫌いじゃないけどね
506:nobodyさん
09/10/14 09:50:38
他のスレで見たが1000円で買った釣り竿が折れたりするらしいｗ
どんだけ阿漕なんだよｗ
507:nobodyさん
09/10/14 09:54:14
>>506
リアルを追求した結果です
508:nobodyさん
09/10/14 13:27:50 r3xTjceB
>>506
ちょw
509:nobodyさん
09/10/14 13:41:19
ネジを回して庭に花が咲くのもリアルを追求した結果ですか
510:nobodyさん
09/10/14 16:36:48 o2uy9WVS
携帯サイトにマイYouTubeサイトへのリンクを張りました。
携帯エミュレーターを使って確認しようとしました。
たぶんYouTubeサイトの中だと思うんですが、動画を再生するボタン？リンクがリンク付けになってなくて押せませんでした。
携帯エミュレーターソフトで動画も見れるものがありましたら教えてください。
さっき使った携帯エミュレーターソフトi ﾓｰﾄﾞ HTML ｼﾐｭﾚｰﾀ２です
511:nobodyさん
09/10/14 18:51:16
相談があります。
携帯サイトをPCで見たいのですが、色々なブラウザを試してみましたが、「このファイルを表示するのに必要なプログラムを探してください」と出て表示されません。
PHPで出来ている、DMMライブチャットの携帯版なのですが。。
宜しくお願いします。
512:nobodyさん
09/10/15 00:28:32
>>511
IP制限（携帯IPからのみ閲覧可能に）されてたらどうやっても無理だろう
513:nobodyさん
09/10/15 07:49:40
>>511
PC版のライブチャットを使えば？
514:nobodyさん
09/10/15 19:32:24
>>250-251
auだけじゃなくてWillcomも似た様な事をした模様。
×のついた２つは元々無かった（前回以前で削除済み？ >>9 の時のか？）みたいだが、
もし隠しで存在してたとか削除漏れだったとかなら、auよりもいい加減過ぎる話だな。
URLﾘﾝｸ(www.willcom-inc.com)
削除IPアドレス帯域(2009年10月15日削除分)
219.108.2.0/24 ×
219.108.3.0/24 ×
125.28.6.0/24
125.28.7.0/24
125.28.11.0/24
125.28.12.0/24
125.28.13.0/24
125.28.14.0/24
211.18.238.0/24
211.18.239.0/24
219.108.4.0/24
219.108.5.0/24
219.108.6.0/24
221.119.5.0/24
515:nobodyさん
09/10/16 10:17:38
もうウイルコム対応はいいだろｗ
516:nobodyさん
09/10/16 15:34:52
まだだ、まだ終わらんよ
517:nobodyさん
09/10/16 16:29:26
>>514
手元のhtaccessの過去ファイルを見たら、前回の３月１９日の修正時にその２つが削除されてた。
>>129 のauの時は削除数が多すぎて、au用IPデータを一旦全て作り直したが、3月19日のWillcom
修正時には、必要なモノのみ修正しただけだから、Willcomのweb上の２つは単に前回の分を消し
忘れてるだけな気も。
518:nobodyさん
09/11/05 19:37:14
128kbpsのPCデータ通信が上限5985円で使い放題―ドコモの「パケ・ホーダイ ダブル」で
URLﾘﾝｸ(www.itmedia.co.jp)
これって使われるIPアドレスは何ジャロね？
もしかしてフルブラウザ用のを使って実現されると、せっかくIPアドレスで
PCアクセスを排除して（るつもり）てもイミフになるが。
尤も、元々のPCでのアクセスがフルブラウザ用IPを使ってない、という証拠も
寡聞にして知らないから、見当違いな心配かもしれんが。
519:nobodyさん
09/11/06 13:16:10
>>518
データ通信をお試しで置いてるショップは多いから自分で見てくればいい
520:nobodyさん
09/11/06 17:20:07
よくは分からんがdocomoのimode用IPアドレスの追加予定が、一部を除いて延期になってた。
もしかして >>518 と関係有るのかもね。本当は128kbpsじゃなくてHSPAの最高速度で実現
しようとしてたのを、低スペックで提供する事でコストダウンを計ったとか。
521:nobodyさん
09/11/07 13:12:22
速度制限のは、もともとPHSから移行した人たちのため。
522:nobodyさん
09/11/09 17:10:58
docomoのXHTML用にhtaccessへ下記を追加した場合、古めなauやSBの３G端末だと駄目らしいが、
どの程度の古さで駄目なんでしょうか？
AddType application/xhtml+xml .html
auのAシリーズ（ブラウザ6.0）あたりは駄目だろうけど、Wシリーズでブラウザ6.2なら何とか
なると嬉しいですが。
特にauの場合、文字コードとの絡みで悲惨らしいが、Shift_JISとUTF-8のどっちで
作った方がより安全でしょうか？（自分はShift_JIS主体です。）
523:nobodyさん
09/11/09 17:25:24
尚、SB の813T だと駄目らしい話や PCのIE7 やFireFoxでも駄目な話は見つけてます。
もし駄目な機種がかなり多い場合、下記の様にphpとかで判定処理プログラムを導入
しなければならないみたいですが、皆さんやっぱりこんな面倒な事をしてるんでしょ
うか？（プロなら当たり前でしょうけど。）
URLﾘﾝｸ(dspt.blog59.fc2.com)
524:nobodyさん
09/11/10 00:08:17
最終的には、そういう機種を切り捨てるかどうかってことだよね。
525:nobodyさん
09/11/10 18:54:11
>>523
とりあえず参照先のphpを見て、簡単そうな対策を検討してみました。
（因みに、imode用XHTML、htaccessファイル、phpを使うのは今回が初めてです。）
（１）.htaccessファイルに下記を追加
AddType application/x-httpd-php .html
⇒拡張子.htmlでphpを動くようにする。
（２）各.htmlファイルの先頭行の <?xml～?> の直後に追加
<?php
if(preg_match("/^DoCoMo\/2\.0/", $_SERVER["HTTP_USER_AGENT"]))
{header("Content-type: application/xhtml+xml");}
?>
⇒UserAgentの先頭が"DoCoMo/2.0"なら、該当のHTTPヘッダを出力する。
（因みに<?xml～?>より前だと、imodeシミュⅡのブラウザ1.0モードでNGだった。）
でも、結局 openwave 6.2シミュだと、この対処をしたhtmlファイルを読み込めなかった。orz
更に利用予定のサクラのレンタルサーバー/ライトコースは、phpが使えなかった。o....rz
526:nobodyさん
09/11/10 19:17:07
そういうところケチるから苦労するんじゃね
最初から携帯向けのレンタルサーバ借りれば済むだろうに
527:nobodyさん
09/11/10 19:52:04
こんなご時世だし、安く済ませようとするのは当たり前な話だろ。
携帯向けレンタルサーバー業者乙！ って感じがする。
528:nobodyさん
09/11/10 20:07:18
>>526
こんな httpd.conf が入ってるサーバって事かな。
DoCoMo FOMA 対応 httpd.conf
URLﾘﾝｸ(mp.i-revo.jp)
BrowserMatch ^DoCoMo/2 want_xhtml=1
SetEnvIf Request_URI "(?<!\.html)$" !want_xhtml
## Below won't work because of mod_headers limitation.
# Header set Content-type application/xhtml+xml env=want_xhtml
RewriteEngine On
RewriteCond %{ENV:want_xhtml} 1
RewriteRule .* - [T=application/xhtml+xml,L]
529:nobodyさん
09/11/10 20:21:32
むしろ携帯向けで125円のサーバとか安く済ませすぎだろ
VPSにして自由にいじれる環境じゃないと携帯サイトは厳しい
530:nobodyさん
09/11/10 21:14:55
凄い簡単そうな方法が有った。本当にこれでOKなら格安で充分でしょ。
URLﾘﾝｸ(www.tansaibou.com)
foma端末以外は「text/html」で出力したい場合は.htaccessを次のように記述。
BrowserMatch ^DoCoMo\/2 foma
AddType “application/xhtml+xml;charset=Shift_JIS” .html =foma
531:nobodyさん
09/11/14 19:07:43
>>522-523
OpenWave 6.2Kシミュレータで試した限りでは大丈夫っぽかったが。
532:nobodyさん
09/11/15 09:08:56
>>529
同意する
533:nobodyさん
09/11/19 03:06:28
やっぱりSBのケータイWiFiって、IPアドレスはY!Keitaiとは別物になるのかな？
iPhoneが別物になってるのは画面サイズとかが大きいから、PC向け頁でもオケ
だから構わんが、画面の小さい携帯端末でWiFi経由で繋がれた場合には、携帯
用頁を案内すべきだと思うが、セキュリティを考えるとIPアドレス判定をしたい。
今のところデベロッパーサイトにも、WiFi経由でのIPアドレスの話は出てない
し、困ったもんだ。
534:nobodyさん
09/11/19 03:35:04
WiFiの意味解ってないだろお前
535:nobodyさん
09/11/19 05:15:50
>>534
ん？ imodeとEZwebはちゃんとやってるみたいだぞ。
第1回 「PCでは見えないはず」に頼ることの危険性
URLﾘﾝｸ(www.atmarkit.co.jp)
一方、日本型のケータイでも、Wi-Fiに対応した機種が登場しつつあります。NTTドコモは昨年からWi-Fi対応機種
（N906iL onefoneおよびN-06A）を販売しており、KDDI（au）は2009年の夏モデル、biblioにてWi-Fiに対応しました。
これらはいずれも、Wi-Fi接続時にも、従来型のケータイインターネット（iモード、EZweb）が利用できることが特徴
です。
これを実現するために、国産のWi-Fiケータイは、端末から直接インターネットに接続するのではなく、いったん
事業者のゲートウェイを通るように構成されています。すなわち、Wi-Fi利用であっても、閉鎖的なネットワークは
維持されています。このように、当面は閉鎖的なネットワークは維持されると思われますが、将来については分かり
ません。この問題については第4回（最終回）で再度触れる予定です。
536:nobodyさん
09/11/19 17:18:00
ハンパな知識で自爆する馬鹿が多いスレだな。
きっと仕事が無いのを不況のせいにして、暇を持て余してるんだろうけど、
謙虚になってもっと良く勉強すべし。
537:nobodyさん
09/11/19 18:03:54
『iPhone』などに Wi-Fi 利用でデータ漏洩のおそれ
URLﾘﾝｸ(headlines.yahoo.co.jp)
SMobile のチームは、OS として『S60』を搭載した『Nokia N95』、『iPhone OS 3.1』を搭載した『iPhone 3GS』、
『Windows Mobile 6.1』を搭載した HTC の端末『AT＆T Tilt』について、保護されていない Wi-Fi ネットワーク
を通じて『Secure Socket Layer』 (SSL) のセキュリティを突破した。『Android』OS を搭載した T-Mobile の
『T-Mobile G1』にも同様の実験を行なったが、報告書では使用した OS のバージョンを明らかにしていない。
538:nobodyさん
09/11/19 18:35:39
スマートフォンだからじゃなくて
暗号化されてない無線に繋ぐからじゃないのかそもそも
539:nobodyさん
09/11/21 16:38:54
というか携帯ならば暗号化されてない無線に繋がらない様にしておくべきだろ。
まあスマートフォンの場合は小型PCみたいなものだから自己責任かもしれんが。
540:nobodyさん
09/11/24 09:10:02
>>533,535
おまえんちのLANにFON設置して、iPhoneからそのFON経由でアクセスした
場合、IPアドレスがどうなるか考えてみれ。
それでわからなければ、もう仕事を変えろｗ
541:nobodyさん
09/11/24 18:02:15
>>533,>>535 の意味はiPhoneの話とは別だろ。
日本語が読めない人は引っ込んでて下さい。
542:nobodyさん
09/11/30 20:05:41
>>533
こっちの情報によると、940SHでの実績だとちゃんとゲートウエイ経由らしい。
ソフトバンクの「ケータイWi-Fi」経由のアクセス
URLﾘﾝｸ(mpw.jp)
無線LAN経由でもリモートアドレスには違いがありませんでしたので、
ソフトバンクのゲートウェイ経由だと思います。
543:nobodyさん
09/11/30 20:10:23
そもそもゲートウェイ内だからそうじゃないからって作り方をするのって
いい方法じゃないと思うんだけど
公式サイトのセキュリティのザルさとか異常だよマジで
544:nobodyさん
09/11/30 22:19:17
>>543
ゲートウェイ経由かどうか（つまりIPアドレス帯域）以外の判定でセキュリティを保てる方法があるなら教えて欲しい
HTTPヘッダを偽られたらトークン使おうが何しようが、結局はID語られちゃうでしょ？
545:nobodyさん
09/11/30 22:38:03
なにその勝手サイト完全否定
公式しかやらない奴ってそういう考えなのやっぱ
546:nobodyさん
09/12/01 11:46:36
お前はいつも否定されるよなｗ
547:nobodyさん
09/12/01 17:10:50 W3Ec24Yf
>>544
禿同
因みに携帯専用の頁をＩＰアドレスで管理してるが、これを特定のＰＣからのみ
閲覧可能に出来ないか、アレコレ検討中。
Domainネーム＋MACアドレスで何とかならんかな～、とオモッテル。
MACアドレスはVBスクリプトでないと読めないが、IE利用を条件にすれば済むし、
Macアドレスの詐称は簡単だが、パスワード解析ほどにはトライ＆エラーするの
が難しいだろ。
あと同じプロバイダー配下のPCと同じMacアドレスになったりしたら、ネット
ワーク自体がトラブル可能性もある？から、あまりトライ＆エラーは行えない
と思うし。
548:nobodyさん
09/12/01 17:16:48 W3Ec24Yf
補足
尚、その携帯専用の頁はBasic認証も行ってるから、PCアクセスした時も同様に
認証は行うつもり。
>>542
流石の金の亡者の禿も、Wi-Fi経由で見れない頁が続出したら利用者から非難
ゴーゴーになるから、iPhoneみたいな真似は出来んかったんだろうね。
549:nobodyさん
09/12/01 17:34:24
>>547
そこまで気を使うサービスをやっているのなら、
固定IPサービス使うのがBEST。
プロバイダーによってはわずかな金額だよ。
550:nobodyさん
09/12/03 15:56:22
>>549
それってユーザー側に固定IPを契約して貰う必要がある？ので面倒そうだが。
まあどういう類のユーザーなのか、に寄るけど。
あと>>547の方法だとユーザー宅内に（大抵は）ルーターとかが有ると、プロ
バイダが認識するのはルーターのMACアドレスだから、同一プロバイダ配下で
同一MACアドレス云々という問題は出ないと思われ。
まあプロバイダのドメインネームでまず制限するのも、MACアドレスで判断する
のも、IPアドレスで行うのに比べれば全然ガードが弱い訳だが、Basic認証のみ
で行うのに比べれば、かなりマシでしょう。
防犯対策と同じで、どんなに完璧そうに見えても完璧にはならないのだから、
あとはコスト対効果見合いで、２重３重に対処するくらいしか無いのだし。
551:nobodyさん
09/12/03 16:09:55
そもそも攻撃者がいちいちマシンのMACアドレス変えないだろw
MACアドレスを元に作成されたHTTPリクエストを偽造するだけだ。
552:nobodyさん
09/12/03 18:54:58
MACアドレスで判定とか。。。
OSI参照モデルから勉強し直した方がいいんじゃないの？
553:nobodyさん
09/12/03 19:04:40
>>547は、管理者がPCでも閲覧できるようにしたい、って事なんじゃないの？
自分は固定IPもちだから、まさに>>549の通りに運用しているよ。
PRGの開発とかソースの調整なんかの途中では、
やっぱりPCで見れたほうが効率がいいからね。
554:nobodyさん
09/12/03 23:59:48
sslのクライアント認証
555:nobodyさん
09/12/04 16:34:49
>>552
なんかこういうヤシが多いな。
ハンパな知識でググリもせずに馬鹿にしてると、何時までたっても仕事は来ないよ。
サーバーからクライアント側のMACアドレスを取得するには？
URLﾘﾝｸ(hpcgi1.nifty.com)
あとルーターorプロババイダの装置のMACアドレスになってしまうらしい？が、
IPアドレスから逆引きも出来る。（ARPコマンド）
URLﾘﾝｸ(www.takebay.net)
>>553
勿論それも有りますが、特定の仲間に見せたい、ってのも有るので。
IPv6が普通な時代になったらオプション月額２００円とか、もしかしたら標準で
固定IPが貰える様になると、固定IP判定が普通になるかもしれんが、現状では
費用対効果を考えると未だ難しいと思う。
例えば一昔前は固定電話の電話番号を家族数人で共用してたが、今じゃ一人一台
の携帯電話で、電話番号も一人一つが当たり前になってるし。
556:nobodyさん
09/12/04 17:41:54
>>555
おもしろすぎるw
Javascriptで入力値チェックしたらサーバーではチェックしなくて良いと思ってる人ですかw
インターネットに公開してるサーバーでARP使って
どこのMACアドレスが取れると思ってるんですかw
557:nobodyさん
09/12/05 00:24:07
>あとルーターorプロババイダの装置のMACアドレスになってしまうらしい？が、
>IPアドレスから逆引きも出来る。（ARPコマンド）
半端すぎてﾜﾛﾀ
558:nobodyさん
09/12/05 00:37:21
参考にしてるリンク先まで貼ってるんだからせめてリンク先に書いてあることくらい
理解してから反論すべきだよな
559:nobodyさん
09/12/05 01:52:25
MACアドレスはそのネットワークに属している機器が同じネットワーク内の機器を識別するために使用
ARPを保持している所でしか意味無いよ。
http等を介して「私はこんなMACアドレスを持っています」って宣言されても意味無いしー（それなんて無線LANハック？ｗｗ）
携帯サイトだけど、管理用パソコンからの通信だけ不特定多数にしたいってんだから、素直にHTTPSのクライアント認証にしなさい
560:nobodyさん
09/12/05 02:34:16
>防犯対策と同じで、どんなに完璧そうに見えても完璧にはならないのだから、
>あとはコスト対効果見合いで、２重３重に対処するくらいしか無いのだし。
いいこと言ってるけど、
あなたが挙げたセキュリティ対策のそれぞれが
どういう弱点を持っていてどのくらいの手間でどうすれば突破できるか、
分かってないだろ。
それが透けて見えるからみんなにバカにされる。
561:nobodyさん
09/12/05 10:13:30
そもそも見られてこまるようなソースをどうにかしろｗ
562:nobodyさん
09/12/07 10:55:05
だからOSI参照モデルから勉強し直せっていってるのに・・・ >>555
563:nobodyさん
09/12/16 23:37:55
【社会】「無料で遊べる」→高額請求…携帯ゲームサイトの相談273件
ｽﾚﾘﾝｸ(newsplus板)l50
564:nobodyさん
09/12/21 10:55:17 2mYzwK9e
なんかみんな対応が厳しいので過疎化しちゃったな。
いいんだよ、どうせみんな低レベルなので気軽に質問してもw
565:nobodyさん
09/12/21 12:43:00
高レベルの回答があったとでも言いたいのだろうか。
566:nobodyさん
09/12/31 07:00:18 /M32rOdj
ここは仕事の来なくなったハンパなプロが、ウサ晴らしするスレだからな。
水呑み百姓が穢多非人を蔑むが如し。
567:nobodyさん
09/12/31 15:56:48
>>566
あんたも WebProg板あっちこっちに下らんこと書き込みすぎだろ。
568:nobodyさん
10/01/12 16:51:10 UYNWXYmi
ＮＴＴドコモの携帯電話のうち、インターネット閲覧ソフト「ｉモードブラウザ２・０」を搭載した最新２９機種を通じて、利用者の個人情報を不正取得される恐れのあることが、専門家の指摘で明らかになった。
同社は携帯サイトの運営者にパスワード認証などの安全対策を呼びかけている。携帯電話の機能が高機能化するにつれ、こうした危険は増しており、利用者も注意が必要になってきた。
該当機種は、昨年５月以降に発表されたプロシリーズやスタイルシリーズなど。ｉモードブラウザ２・０は、ジャバスクリプトと呼ばれる機能が組み込まれており、携帯用のインターネットサイトと自動で情報をやりとりできる。
悪意ある携帯用サイトは、接続してきた利用者の携帯のジャバスクリプトを使って、利用者が会員になっている別のサイトに一瞬だけ接続させることができる。その時、この会員サイトに利用者の住所など個人データが登録されていると、盗み出されてしまう。
情報通信機器の安全管理を手がける「ＨＡＳＨコンサルティング」（横浜市）が、こうした悪用が起きうることを、実験で確かめた。被害はまだ確認されていない。
ドコモを含む各社の携帯電話には、１台ごとに割り当てられた「利用者ＩＤ」だけで携帯用サイトに認証され、手動入力を省略できる機能がある。今回判明した危険は、この機能にジャバスクリプトが加わることで生まれた。会員サイトが利用者ＩＤに頼らず、
パスワードの確認入力を求めれば、悪用を防げる。利用者側も、パスワード確認を求めないサイトなどには、個人情報を気軽に書き込まないよう注意が大切だ。
ＮＴＴドコモでは、公式サイトを運営する約３０００社には注意喚起したが、それ以外の無数にある「勝手サイト」には「ジャバスクリプトの安全な利用はサイトを作る側にとって基本的知識であり、具体的に説明はしていない」という。
産業技術総合研究所情報セキュリティ研究センターの高木浩光主任研究員は、「利用者ＩＤがあらゆる携帯サイトに自動で送られ、認証に使われる仕組みは問題だ」と指摘している。
URLﾘﾝｸ(www.yomiuri.co.jp)
ｽﾚﾘﾝｸ(news板)
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5274日前に更新/151 KB
担当:undef