俺の脳内選択肢が、SQLインジェクション対策を全力で邪魔している — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
PHP Advent Calendar 2013 in Adventarの19日目です。昨日も私の「PDOでの数値列の扱いにはワナがいっぱい（2）」でした。 うっかりtogetterなんか見てしまい、無駄に時間を使ってしまったと後悔した上に混乱してしまい余計にわからなくなってしまった人もいるかも知れません。 そこで、せっかくの機会なので、SQLインジェクション対策について、現在の私の考えをまとめておこうと思います。 選べ ①SQLインジェクション対策にプリペアドステートメントを使う ②SQLインジェクション対策にエスケープを使う もし、上記のような選択にはまってしまったら、あなたのSQLインジェクション対策は、現実的には、ほぼ100％間違っていると言えるのではないでしょうか。プリペアドステートメントとエスケープは、このような対立構造にはありませんから。 なお、この記事は、SQLインジェクシ
10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 - 日々、とんは語る。
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
013 同一レコードを複数ユーザが同時に変更してしまうのを防ぐには？ - EC-One ナレッジセンター レスキューサービス ブログ
こんにちは、id:EC-OneのAkiです。 梅雨も明けて30度を超える暑い日が続きますが、みなさんいかがお過ごしですか？ アイスの食べ過ぎは夏バテの元ですよ！ 今回は、Webアプリケーションのちょっと生っぽい実装テクニックのお話です。 同一レコードを複数ユーザが同時に変更してしまう？ データベース内の特定のレコードを変更するWebアプリケーションを考えてみます。たとえば、「取引先マスタの変更」を行うアプリケーション等です。 この場合、このアプリケーションは以下のような流れになるでしょう。 ユーザがデータ編集画面に入るボタンをクリック。 サーバが現在のデータをデータベースから取得＆返却し、それをユーザのブラウザが表示する。 ユーザがデータを編集し、編集結果反映ボタンをクリック。 このとき、変更した項目も変更していない項目も一緒にサーバに送られる。 サーバが編集結果をデータベースに反映する。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSL Server Test (Powered by Qualys SSL Labs)
MySQLチューニング
