【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方SQLインジェクションを・・・駆逐してやる！！ この世から・・・一匹残らず！！ (PHPカンファレンス2015)
Webアプリ開発をする上で読むべき本とか - catatsuyとは
Web アプリ開発をする上で読むべき基本的な本は無いかと聞かれて，すぐに出てこなくて困った 今後もそういうことを聞かれることもあるかもしれないので個人的にまとめておきたい 基本的には何かを作ってみて，習うより慣れろの精神で行くのがいい 最近は Ruby on Rails が流行りな気もするのでその辺りで役に立ちそうなサイトを紹介する Ruby on Rails チュートリアル：実例を使って Rails を学ぼう サクサク引ける Rubyリファレンスマニュアル bbatsov/ruby-style-guide Rails のチュートリアルはたくさんあるので他にも読んでみると良いかもしれない ただ Ruby on Rails が簡単というのはウソ - #生存戦略 、それは - subtech に書かれていることを全部やろうとすると絶対にハマるので分かるところから少しずつやるといい それと We
配列から効率良くプレースホルダを作る : にぽたん研究所
my @a = qw(foo bar baz); こんな配列から ?,?,? という文字列を使いたい場合があります。 例えば、 SELECT * FROM hoge WHERE user_id IN (?,?,?); みたいな SQL にする場合のプレースホルダを作ると言った具合に。 社内 IRC で、clouder さんが言い出して、 18:27 <clouder>join(',', map('?', @a)) 18:27 <clouder> こんなのしか思いつかない。。 と言う。 まぁ、それが妥当というか、普通それが思い浮かぶよなーって思ってたら、会社の dos さんという人が 19:15 <dos> '?,' x @a; で s/,$//; というｿﾘｭｰｼｮﾝ とか、異様なことを言い出した。 sub placeholder_from_array { return join(',',
O/R Mapper におけるページャーの実装について - tokuhirom's blog
欠点$rs->pager(); のように、クエリをうっているっぽくないのに裏でうってるので、重い処理なのにおもそうにみえなくてさがすのが面倒。お気軽につかえすぎて危険。 HAVING などをつかうクエリの場合、そもそもただしい値がとれてないのに、なんとなくうごいてしまう。まちがった値をかえす API を標準でつけるのはいかがなものか。 得に HAVING などの処理がうまくできないのは自明なので、こういう実装は僕は好きではないです。 → Teng にはついてない。
『よくわかるPHPの教科書』のSQLインジェクション脆弱性 - ockeghem's blog
このエントリでは、数値型の列に対するSQLインジェクションについて説明します。 以前のエントリで、たにぐちまことさんの書かれた『よくわかるPHPの教科書』の脆弱性について指摘しました。その際に、『私が見た範囲ではSQLインジェクション脆弱性はありませんでした』と書きましたが、その後PHPカンファレンス2011の講演準備をしている際に、同書を見ていてSQLインジェクション脆弱性があることに気がつきました。 脆弱性の説明 問題の箇所は同書P272のdelete.phpです。要点のみを示します。 $id = $_REQUEST['id']; // $id : 投稿ID $sql = sprintf('SELECT * FROM posts WHERE id=%d', mysql_real_escape_string($id) $record = mysql_query($sql) or die(
『アメブロで行ったチューニングの紹介』
はじめまして。ブログを担当しているNと申します。 ブログ絡みの技術ネタをと依頼をされましたが、 ブログは枯れた技術を多く使っていて目新しいことはあまりないので、 以前行ったチューニング内容について紹介したいと思います。 2008年にブログの記事データについて行ったDB+アプリでのチューニングです。 ブログの記事データはMySQLのMaster-Slave構成で保持していて、 Slaveサーバーをスケールアウトしてブログの閲覧のリクエストを処理しています。 SlaveのMySQLのバージョンは4.1でEngineはMyISAMです。 記事テーブルには以下のようなデータを保持しています。 記事ID,ブログID,記事タイトル,日付,テーマ,公開区分,ステータス,･･･ チューニング前の記事テーブルには以下のようなINDEXを張っていました。Key_name Seq_in_index Collat
O/R Mapper についてかんがえてみた
元ネタ）http://d.hatena.ne.jp/tokuhirom/20110104/1294170319 昔良くORMを使うことのメリットは SQLを書かなくてよくなる。 つまりプログラマはSQL脳が低いからプログラマにSQLを書かせない。 プログラム中にSQLという別の概念がはいってくるとコードが読み難くなる。 バックエンドのRDBMSの差異を吸収してくれるからバックエンドを気にする必要がない。 さらに、バックエンドのRDBMSを簡単に取替え可能。 プログラマブルにSQLを組み立てしたい。 などと言われることが多いんじゃないでしょうかね。 個人的には最後の「プログラマブルにSQLを組み立てしたい」と言う要件以外は全部 間違っていると思います。 イカ全て自分の視点なだけなので違う意見もあるであろうことを承知で言い切ります。 SQLを書かなくてよくなる。つまりプログラマはSQL脳が低い
SQL::Makerで動的に SQLを生成する - Articles Advent Calendar 2010 Hacker
どうもこんにちは。hacker track がやる気なさすぎるのでもう一回かくよ!というわけで tokuhirom ですこんにちは。こんにちは。 さて、最近つくった SQL::Maker というモジュールについて紹介します。SQL::Maker は、要は SQL::Abstract みたいなやつです。じゃあなんで SQL::Abstract じゃなくて SQL::Maker なの？ってことになるわけですが、 SQL::Abstract は実績があるし、非常に便利なんですが、いかんせんコードがまじよみづらいっていうかこれよむの無理じゃね!!ってことをおもうので、あたらしくつくったという次第。 また、SQL::Maker は method chain で SELECT 文を構築する機能もついてます。あらべんり。こんなかんじ↓↓ my $sql = SQL::Maker::Select−>new
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
