10/02/17 14:36:29
>>640
クレジット決済は代行会社に申し込んで
その会社が指定する方法でデータのやり取りをするから、とりあえずは申し込みor問い合わせすべし
SSLはサーバ側の設定とスクリプト側ではHTMLのリンクだけ注意
642:nobodyさん
10/02/17 15:15:51
一個人がカード会社と直接は契約できないので、
決済代行と契約してくださいな。
643:nobodyさん
10/02/17 15:25:26
お勉強のためならそこまでしなくてもオレオレ証明書でSSL通信して
カード情報入力→一部伏せて確認画面→注文（で、情報取得可なことを確認）
これぐらいでいいと思うよ。
「注文」のとこでカード情報を決済代行屋さんにどう投げるのかとかは
実際に契約する用事ができたときに考えればいいんじゃないかな。
644:640
10/02/17 16:00:22
>>641-643
お三方レスいただきありがとうございます。
カード会社の件は了解いたしました。
代行によって違うということは、
実際に申し込んで見ないとどういうものかは分からなそうですね。
とはいえ実際にネットショップを開くわけではないので
とりあえずカードは未対応で作ってみたいと思います。
どうもありがとうございました、
645:nobodyさん
10/02/20 15:31:05
PHPscriptが動作しているOSの種類やバージョンが分かる関数はあるのでしょうか？
改行コードのバイト数を「 strlen(PHP_EOL) 」で判定する
参考URL
URLﾘﾝｸ(blog.fukaoi.org)
また日本語名を含むファイルをアップロードした際に日本語が化ける問題はどう対処すればいいのでしょうか？
アップロードしたファイルのファイル名を動作しているOSに合わせて変換はできますか？
参考URL
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
mb_internal_encodingはPHPの設定ですが、OSの設定を知る事はできないのでしょうか？
教えて！エロイお姉さん！
646:nobodyさん
10/02/20 15:42:59
コピペうぜぇえ
647:nobodyさん
10/02/20 15:50:25
マルチ乙
648:nobodyさん
10/02/20 18:02:46
>>645
phpinfo
649:nobodyさん
10/02/24 08:55:37 bh88JagV
あ
650:nobodyさん
10/02/24 11:06:11
>>649
うん
651:nobodyさん
10/02/24 13:53:11
阿吽の呼吸ですね
652:nobodyさん
10/02/24 16:14:39
いい感じです
653:nobodyさん
10/02/25 17:47:14
もっこりしてきました
654:nobodyさん
10/02/26 00:23:13
mixiアプリ上のゲームやツール類の開発言語はなんでしょうか？
あれは普通にフラッシュゲーム類なのでしょうか？
655:nobodyさん
10/02/26 00:44:39
javascriptだろ
656:nobodyさん
10/02/26 09:47:43
サンシャイン牧場とかああいう凝ったゲームもjavaなの？
657:nobodyさん
10/02/26 09:56:14
>>656
HTMLのソースみなよ。
Flashならソースみるまでもなく単に画面で右クリックして
「Adobe Flash Player 10 について」ってでてくればFlashだよ。
658:nobodyさん
10/02/26 09:58:24
とは限らない
Flash「も」使っているだけかもしれない
659:nobodyさん
10/02/26 10:01:11
そりゃそうだろ
660:nobodyさん
10/02/26 10:24:33
そりゃそうだろって中身の実装が何かが分からないってことを言ってるのだが
クライアントがFlashなだけでJavaでシステム組んでるかもしれないじゃん
661:nobodyさん
10/02/26 10:26:06
そうだね
662:nobodyさん
10/02/26 10:50:56
開発言語はなんですか？→知るかボケ本人に聞け
作れますか？→やる気と技術があれば作れるんじゃね
663:nobodyさん
10/02/26 14:43:06
作れますか？→お前には無理
664:nobodyさん
10/03/08 11:36:16
そうですか、てめぇの意見参考になりました。
665:nobodyさん
10/03/08 12:25:14
作れますか？→お前次第
666:nobodyさん
10/03/08 18:02:10 2nbdnXAH
管理画面を作っています
form.php?mode=change&id=100
のURLでid100の商品の情報を変更する仕様で、
編集用のフォームを出力するんですが、idに値がセットされていないときは
当然編集対象が不明になってしまいます。
こういうとき、どうしてますか？
１）警告画面を出力する。（idが不明です。編集対象の商品が不明です。 みたいなメッセージを出す）
２）他のページの同様のエラーもまとめて一つのエラーページに飛ばす。メッセージは「不正なアクセスです」のみ。
３）何もしない。（既存の情報をフォームにプリセットさせる処理などができないけど無視）
一つ前の画面で「この商品の情報を変更する」などのリンクを普通に踏んで来てくれれば
idがセットされてないなんて事はありえないという構造を前提にアドバイスください。
わざわざid値を消すような奴は無視で良いのかな？
このページに限らず、そんなヘンな処理を一つ一つ対応してたらきりがない気がして相談しました
667:nobodyさん
10/03/08 18:35:46
Webプログラムの基本的な考え方は、クライアントから渡される情報は
すべてチェックしろ、ってのが原則だ
それを踏まえた上で、システムの動作に問題がないのなら好きにしろ
668:nobodyさん
10/03/08 18:39:52
そういうのって、クライアントがどうしたいかによるんじゃね
どれが正解とかあるの？
明らかに不正なのの、対処は必要だけど
669:nobodyさん
10/03/08 19:28:15
渡される値を１００％信用しちゃ駄目
ってことで＞答え
670:nobodyさん
10/03/08 23:06:43
>>666
＞ １）警告画面を出力する。（idが不明です。編集対象の商品が不明です。 みたいなメッセージを出す）
パラメータの過不足はバグ取り用にしか出さない方がいいと思う。利用者に見せると「あーこれがIDなのか、じゃぁここをついて・・・」みたいに悪用する暇人もいる。
＞ ２）他のページの同様のエラーもまとめて一つのエラーページに飛ばす。メッセージは「不正なアクセスです」のみ。
これが無難かな。
＞ ３）何もしない。（既存の情報をフォームにプリセットさせる処理などができないけど無視）
サイト自体がおかしいからサヨナラしようかなと思われるから、ノーリアクションはまずい。
私なら、型チェック（期待したストリングか）は当然のようにした上で、IDがないならログインへ、商品がないなら商品選択画面へ戻すかな。親切すぎないほうがいいとおもうけど。
悪意がないけどIDが期限切れで抹消されてるとかありえるしね。ユーザ逃がしちゃ意味ないし。
※ 蛇足だが、中途半端なリンカーソフト(メモ帳に毛の生えたやつとか)から長いURIで飛ぶと?以降が切れてたりするので、いちおうフォロー入れてもいいかなっと。
671:666
10/03/08 23:26:29 2nbdnXAH
皆さんどうもありがとう
>>670
すごい親切ですね
どんどんコードが長くなっていくなあという感じで、めんどくさいってのが本音だけど
そういうエラー時の処理の流れを管理するクラスのようなものを作ってるんでしょうか？
どのサイトでもちょっとの修正で使いまわせるような…
たぶん、コードが綺麗なんですね。そうじゃなきゃ見づらくなる一方でイライラするし。
もう一つ聞きたいんですが、データのSQL登録やselectで失敗したとき、どうしてるんですか？
エラーをキャッチしたら適宜メッセージページに飛ばしつつ、
エラー情報を管理者にメールするとかしてるんですか？ それくらいやるのがプロとして当たり前？
自宅サーバで操作してる分にはクエリの失敗なんて起きないので、
実際にそんなことがどんな頻度でどんなときに起こるのかわからなくて、いまいち重視してないんですが…
672:nobodyさん
10/03/09 00:21:17
>>671
＞ データのSQL登録やselectで失敗したとき、どうしてるんですか？
時間がたったらやり直してね（うふっ） です。「接続できませんでした」みたいなそっけないのは普通の人に意味がないので出しません。
遷移した画面でユーザ側が「あー、データ登録できてないな」って確認できるのが前提で、
超大事なフォーム入力データはDBに書いたのをまたHTMLで返して、最終確認でポチってもらって、そのときにhiddenで送ったデータとDBから読み出したデータが合えばOK。
DBでエラー吐くたびにメール出してたらそっちのが累積して鯖固まるのではないかと。
673:nobodyさん
10/03/09 00:24:41
ログに吐けばいいだけじゃねーの。
メール飛ばすかどうかはログ監視でやればいいだけの話だし。
674:nobodyさん
10/03/09 00:58:21
>>672-673
ありがとうございます、すごい勉強になります。
＞DBでエラー吐くたびにメール出してたらそっちのが累積して鯖固まるのではないかと。
そんなに頻繁にDBてエラーするんですか？
フォームデータのバリデートするのは当然の前提でもですよね？
プログラムだけの対応じゃどうしようもないエラーってことでしょうか
たとえばどういう条件でおきるものなんですか？
＞ログ監視でやればいい
なるほどー
くどくてすみません
675:nobodyさん
10/03/09 01:13:46
>>674
トランザクションやロック処理で調べるとDBやファイルの扱いで延々とコケる説明が出てきます。
HTTP経由なら同時接続数自体を絞れば、DB側がボトルネックにならずにすむんじゃね。セッションさえ残っていればリトライできるんだし。
676:nobodyさん
10/03/09 01:28:22
>>674
そんなに起きないよ
でも仮に何かの原因で１ページ１０～２０のクエリが失敗した場合が、その数xアクセス数のメールが飛ぶぞw
ログに書き出せばおk
677:nobodyさん
10/03/09 19:09:06
JavaScriptについて教えてください。
JavaScriptでクッキーを削除したいのですが
Firefoxでは削除されないようです。
ググってみたところ下記の方と同じようです。
URLﾘﾝｸ(questionbox.jp.msn.com)
何かよい方法はないものでしょうか？
678:nobodyさん
10/03/09 19:44:49
設計からやり直す
679:nobodyさん
10/03/10 00:47:13 OK6KN61F
フォームの登録処理（DB)のあと、完了しましたって画面にリダイレクトさせてるんだけど、
そこからブラウザの戻るボタンで戻られても二重登録にならないようにしたい。
どうするのがおすすめ？
DBに入れる登録用データがセッション使って登録画面まで引き回されてる作りなんですが
リダイレクトした完了画面でセッションを破棄させる対応で大丈夫ですか？
（セッションがなかったら警告ページにリダイレクトで）
もっといいやり方ありますか？
680:nobodyさん
10/03/10 01:04:27
>>679
セッションクリアでいいんでない？
あとメアドとかだったら二重登録自体できないようにするとか画像認証いれるとか
681:nobodyさん
10/03/10 02:42:10 OK6KN61F
>>680
ありがとうございます。
セッションクリアだけで大丈夫でしょうか？
ページ戻ったら、セッションのキャッシュがあってそれで再送信されるなんてことないかな
セッションはサーバーに保管してるものだからブラウザのキャッシュなんて関係ないかな？
知識不足ですね、どうなんでしょう？
682:nobodyさん
10/03/10 03:15:39
セッションがあってもセッションデータがなければ大丈夫
683:nobodyさん
10/03/10 16:53:26
心配なら突合せ処理も入れればいいんじゃね。変な鯖じゃなければCPUに余裕あるだろうし。
684:679
10/03/10 22:17:53
>>680-683
ありがとうございます。とりあえずセッションクリアで対応してみます。
685:nobodyさん
10/03/14 00:05:26 e6JahMR0
空メールを送ってもらい、登録URLを送り返して個人情報を入力してもらい登録、
登録後はメール配信を行うシステムの構築を考えています。
MySQLを使って情報をデータベース化しても良いのですが、
サーバーが専用サーバーではなくVPSでの運用で、さらにMySQLの知識や経験がほとんどなく、
セキュリティ面が心配なため、登録メールを端末PCで、メールで受信してローカルで保存することを考えています。
ローカルのデータベース化および配信は専用ソフトを使うつもりですが、
専用ソフトの登録情報取り込みがPOPのみでサーバから端末PCまでが暗号化されません。
多少無理してでもSQLで運用した方が良いのか、それともサーバから端末までの
経路での不安を抱えながらが良いのか、識者の方のお考えを伺えたらと思っております。
686:nobodyさん
10/03/14 00:18:42
DBに格納すれば安全なわけでもないし、
メール受信が平文なら他でいくら心配しても無駄ではない?
687:nobodyさん
10/03/14 00:21:56 nHgOFBBV
きっと気にしなくても平気だろうけど
専用ソフトがなんだかわからんけど
個人情報受け取ったcgiが暗号化してメール投げる
受け取っててもとで平文にしてdbにいれる
専用ソフトは暗号化されたsendmailを使う
とかできるんじゃね
688:nobodyさん
10/03/14 00:58:46 e6JahMR0
>>686
やはりDBでも安心はできないですよね。
>>687
PHPでの実装を考えています。
専用ソフトは、指定した書式のメールを受信して取り込み自動的にDBに書き込みます。
配信は別のソフトで、こっちはPOPoverSSLに対応しています。
別のメーラーで一度SSL通信で受信後、DBに書き込むことは可能ですが、
あまりにも手間がかかってしまいます。
ユーザー －登録情報(SSL通信)→ サーバー
サーバー －PHPで指定書式にした登録情報のメール(非SSL POP)→ 管理PC
もしくは
サーバー －登録情報(SSL)→ 管理PC 指定した形式に都度変換→DB
といったところでしょうか。
登録ユーザーは別途名簿があり、対象者に直接書面で登録URLを知らせます。
登録情報はメールアドレスと氏名、登録区分程度で、ウェブなどには公開しないのですが、
それでも平文でメールが流れるのはリスクを伴いますよね。
リスクと手間、どこかで妥協しなければならないですよね・・・。
689:nobodyさん
10/03/14 03:42:39
ログイン機能のあるウェブサイトのＤＢ設計で
「ユーザテーブル」と「ログイン情報テーブル」のように分けるケースをよく見かけます。
（ユーザテーブルに名前や住所や電話番号などを格納して、ログインテーブルにログインＩＤとパスワードを格納する感じ）
ユーザテーブルにログインＩＤやパスワードを保持するのは何か問題あるのでしょうか？
ユーザとログインＩＤは通常１：１の情報だから同じテーブルに入れるのが筋だと思うのですが。
690:nobodyさん
10/03/14 03:44:04
いや問題はない
利便性のために意図的に正規形を崩してるだけ
691:nobodyさん
10/03/14 05:17:43
>>689
ORMとかリレーショナルデータベースでググレ
692:689
10/03/14 10:09:58
>>690
>>691
ありがとうございます。
利便性というのは具体的にはどのような効果があるんでしょうか。
ORMがヒントであるなら、ユーザ情報とログイン情報を別のクラスとして扱いたいということですか？
むしろ面倒くさくなりそうです。
一般的にはログイン後にユーザ情報を取得すると思いますが、
ユーザテーブルとログイン情報テーブルにテーブルを分けてしまうと、ログイン処理の度に二つのテーブルを参照する必要がありますよね。
693:nobodyさん
10/03/14 21:21:48
たとえば、ログインするのに、そのユーザの住所や電話番号が必要か？
ログインＩＤとパスワードだけでいいのに、不要な情報まで取得するのは無駄だとも考えられるだろ
まあ、ログイン処理で実テーブルの構造考えるようじゃ、
ＯＲＭやる意味ないけどな
694:nobodyさん
10/03/14 23:04:07
すいません、xampp について質問する板はここでいいんでしょうか。
もし違うなら板を教えてください。よろしくお願いします。
695:nobodyさん
10/03/14 23:06:25
>>693
その理由だけだと、いらない情報はselectで外せばいい、と返されてしまうよーな。
696:nobodyさん
10/03/14 23:43:24
>>695
アプリ側だけみればその通りだがDBMSの動作って範囲で考えると違いがでてくることもある
まあ、実際に動作的な問題でテーブル分けてる場合は少ないと思うが
（とくにロックを長時間保持することのすくないＷＥＢアプリなら）
ほとんどは設計が適当だったりした結果別テーブルなだけだと思われ
別テーブルであることに明確な理由はなく
将来の拡張に備えてとか言う言い訳がついたりするパターンだな
697:nobodyさん
10/03/14 23:47:37
利便性
拡張性
便利な言葉だね
698:nobodyさん
10/03/15 00:06:56
金取るためにゃ便利な言葉さ
699:nobodyさん
10/03/15 10:05:19
基本的に、変更がありえないものだけで1つテーブル作って
それ以外は分けるべき。キリが無くなるし、
あとで別の人がメンテしようとしたときにうんざりする
700:nobodyさん
10/03/15 16:32:50
もうDB板の範囲。WebProgに特化した話題じゃないし。
701:nobodyさん
10/03/16 00:42:52
>>694
下記にあったよ
xamppってどうよ？
ｽﾚﾘﾝｸ(mysv板)
とりあえず何につまづいてるのかわからないと詳しい誘導もできないだろな。
702:nobodyさん
10/03/16 01:23:04
投稿サイト作ってるのですが
各投稿に番号をつけようと思って
投稿時間(UNIX値)を使いたいのです。
これを重複させないようにするには
ファイルロックしながらtime()関数を使えばいいのでしょうか?
703:nobodyさん
10/03/16 01:41:43
何故データベース設計は軽視されるのか？
ｽﾚﾘﾝｸ(db板:446-447番)
704:nobodyさん
10/03/16 01:51:17
>>702
それなら時間＋区切り文字+固有のID（プロセスでもなんでもいい。）かな。
IDはユニークでなきゃだめなんだから、ロックしていてもかぶるかもしれんのは使いたくない。
705:nobodyさん
10/03/16 02:52:29
いろいろ参考になりました!
706:nobodyさん
10/03/16 07:26:49
ファイルロックのときに１秒待てばいいんじゃね？
707:nobodyさん
10/03/16 13:03:13
>>702
あちこちで聞いてるね。
答えようと思ったけどどこで答えたらいいか迷うので答えない。
708:nobodyさん
10/03/16 13:07:20
答えなくていいよｗ
大した知識があるわけじゃないだろうし
709:nobodyさん
10/03/16 14:03:21
そんな風に煽ってみたってマルチには答えないよｗ
710:nobodyさん
10/03/16 17:18:04
あちこちってどこだよ
711:nobodyさん
10/03/16 17:21:36
そっちだよ
712:nobodyさん
10/03/16 17:33:39
あっちこちっていいとも!かよｗ
713:nobodyさん
10/03/16 18:38:06
んなこたーない
714:nobodyさん
10/03/17 00:59:17
>>701
ありがとうござます。
移動します
715:nobodyさん
10/03/17 01:57:10
ChatPadとかのWebベースのチャットって
ajaxとphpと共用サーバーで実現可能ですか?
やっぱプログラムを常駐させないといけないんでしょうか?
716:nobodyさん
10/03/17 02:26:38
とりあえずそこらに転がってるフリーのチャットとか設置してみ。
717:nobodyさん
10/03/17 02:40:39
d(ﾟДﾟ )☆ｽﾍﾟｼｬﾙｻﾝｸｽ☆( ﾟДﾟ)b
718:nobodyさん
10/03/18 22:44:29
リンクをクリックすると、画面遷移させずにその下に詳細情報を表示させるような
画面を画面を作りたいと思っています。
詳細情報はクリック時に取得する必要はないので、
この画面をロードする際に予め取得していて、表示はさせない(隠しておく)、
というのが簡単なのかな、と考えているのですが
このような画面を実現するにはどのようにすれば良いのでしょうか？
719:nobodyさん
10/03/18 22:50:34
>>718
CSS
720:nobodyさん
10/03/18 23:19:45
>>719
リンクのonclickイベントハンドラでdisplayの値を切り替えれば良い、ということですかね。
ありがとうございます。
721:nobodyさん
10/03/18 23:19:53
javascript block 表示非表示
722:nobodyさん
10/03/18 23:52:27
>>721
ありがとうございます。
やりたいことそのもののサンプルを載せられてるページを見つけることができました。
URLﾘﾝｸ(www.plasmasphere.net)
723:nobodyさん
10/03/19 15:22:55 RgXX4bEl
pixivというイラスト投稿サイトを見てたら、
表示する画像＆情報を指定するらしいパラメータがあり、適当に数字入れて変更したら
画像は表示されずにトップページやカテゴリトップにリダイレクトされました
これは、
・一度DBに変更後のパラメータで情報を問い合わせる。
・該当情報がなかったので指定のリダイレクト先に転送。
っていう流れをしているんでしょうか？
724:nobodyさん
10/03/19 15:37:40
そうだろうね
725:nobodyさん
10/03/19 17:02:00
親切に詳細なエラーとか出すと攻撃の糸口を教えてるようなもんなので、
Moved とか返したりしてリダイレクトするのが一般的
と、自分は勝手に解釈してる。
726:nobodyさん
10/03/20 02:45:47 Y7vxP7W2
>>718
ahah使えば、クリック時取得でも簡単だぜ。
727:nobodyさん
10/03/20 04:34:56 2Jzz4mSF
「<>'ﾞ&」さえサニタイジングしておけばXSS対策は万全ですか？
728:nobodyさん
10/03/20 10:22:15
万全です