.htaccessで特定のIPアドレスのみアクセスを許可する

会社や自宅などの特定の場所からのアクセスは許可して、そこ以外の場所からのアクセスにはBasic認証をかけたいということがあった。

すごく参考になるページがあったのでメモ。
BASIC認証とIPアドレス制限の併用


まずは全文。

AuthType Basic
AuthName "Please enter username and password"
AuthUserFile htpasswdへのパス
AuthGroupFile /dev/null
require valid-user



Order Allow,Deny
Allow from 「特定のIPアドレス」
Allow from 127.0.0.1


Satisfy Any




これを分解していくと

Order Allow,Deny
これで一旦すべてのアクセスを拒否してる

Allow from 「特定のIPアドレス」
Allow from 127.0.0.1

これで特定のIPアドレスからのアクセスのみ許可する。
127.0.0.1とは、自分自身を指す特別なアドレスのこと

ちなみに

Allow from all //全部
Deny from example.com //ドメイン名で指定


という指定方法もあるらしい


Satisfy Any

これはID/Pass制限とアドレス/ホスト名で制限の両方が設定されている時にの動作を決めている


Satisfy Any
だったらどちらか片方

Satisfy Alll
だったら両方とも条件を満たす必要がある


参考：アクセス制限の記述(Order, Allow, Deny)

自動でサイトのテストをしたい

JMeterっていうアプリケーションがあります。
サイトの負荷テストをするためのアプリケーションです。

作成したページの表示は1人でも確認できますが、実際に本番で多くのユーザーがアクセスしてきた場合はどうなるのかってのは1人では調べづらい。
JMeterってのは、本番の様にサイトに負荷をかけつつテストすることができるアプリケーションのようです。

今のところ僕は負荷テストではなく、サイトのページの確認用に使ってる。
たとえば、webアプリケーションのシステムを大きく変更したとか、共通で使用している部分を変更したって時に、思わぬとこでエラーが出たりする。
それを1人で全部チェックするってのは難しい＆馬鹿らしい。

JMeterってアプリケーションに確認したいページをすべて登録しておいて、エラーが出ていないかどうかを判定してる

使い方などを詳しく掲載している記事があったのでどうぞ
JMeterでWebアプリケーションのパフォーマンス測定を行う

[Symfony] layout.phpを変更する

使用するレイアウトファイルをデフォルトのlayout.phpから変更したい場合は、アクション内で
$this->setLayout('new-layout');
とすればいい

↑の場合はアプリケーション/template/new-layout.phpを使用するようになる

ウェブアプリの高速化

実践・ウェブアプリ高速化テクニックという記事を読んで思ったことをメモ。

上記の記事の要点
・高速化とはプログラムの処理スピードなどではなくUser Experience！
・ユーザーが快適にサービスを利用できているかが重要
・快適→ユーザーが起こしたアクションへの迅速なレスポンス。実際の速さよりもユーザーが速いと感じることが重要
・Gmailのスターはローディングも出さずに反映する

高速化を考える際に、ユーザーのことを忘れているというのは同感。自分もよくそうなる。
処理速度をあげるってのは、計測できるという点からすると、けっこう楽。
やり方によって実際に処理にかかる時間が目に見えてへっていくからね。

それに比べて、ユーザーがどう感じてるかを考えながら作るのはなかなか大変。
作っているこっちは何十回、何百回と同じことをくりかえしたりするので、もう感覚がわからなくなったり、秒数を減らすのと違って、どういうふうにすれば快適だと感じるかというノウハウを持っていなかったりする(俺の場合ね)。

重要なのは何かしらのレスポンスの速さってことかな。

・オンマウス時のリアクション
・クリック時のリアクション
・ローディング時のリアクション

まずは一瞬でもレスポンスがないような状態をなくす。

・ローディング時のプログレスバー・読み込み完了度の表示
これはただ「Loading...」とか出ているのとは気持ちはかなり変わる。
いつまでかかるかわからないような処理は待ってもらえない。

・エラー時のリアクション
なぜエラーが起きたのかが明確に伝える
エラーの解決方法を伝える

他にも色々ありそうだなー

MVCのお勉強。太ったモデルと痩せたコントローラ

下の2つの記事を読んで、すこし理解が深まったような気がしているのでメモ
Web アプリの MVC 設計まとめ :: もやし日記
えせMVCについてそろそろ一言言っておくか :: ひがやすを blog

CakePHPを使ったMVC設計のベストプラクティスを読んで、ビジネスロジックはモデルに置くべきだと認識した。コントローラーをシンプルにしておけば処理の流れもわかりやすいだろうと。

特定のモデルに大量のメソッドが集中したり、どのモデルがどういうトランザクションを担当するのかが分かりにくくなってきて、コードの可読性は下がり、重点的にテストすべき場所も分かりづらくなってきます。
Web アプリの MVC 設計まとめ :: もやし日記

確かに機能が増えてモデルが多機能になりすぎることはありそう。
実際1つのカラムの値を取得したいだけなのに、多機能なインスタンスを作らないといけないってのもメモリーの無駄遣いかも。
あるコントローラでしか使われていない機能があるってのも気になる。

次の間違いは、Skinny Controller, Fat Modelが最良だと信じている点。
Fat ModelはFat Controllerと同様にテストはしにくいし、理解しづらくなる。ロジックはそれぞれ適切なところで実装すべきで、Fatなのはやはりよくないのです。
えせMVCについてそろそろ一言言っておくか :: ひがやすを blog

ふむふむ。やはり過ぎたるは及ばざるが如しですな、と脳みそ停止しきってるくせに理解したふりしてみる。
コントローラーとモデルの両方をテストしないと確実じゃないってことになったら、そのテストってなんなの？って感じはするな。

追記:一昔前のフレームワークなら、ControllerはWebのAPIに依存していてテストしにくいというのもあってControllerからロジックを追い出せということがよく言われてきましたが、いまどきのちゃんとしたフレームワークは最初からControllerもテストできるように考慮されています。
えせMVCについてそろそろ一言言っておくか :: ひがやすを blog

そもそも、コントローラーにロジックを置かない理由の1つがテストしづらいからだったの？
他にはどんな理由があるんだ？コントローラはロジックを置くとこじゃないってのが1番の理由だと思ってたんだが…どうなんだろう。

きっちりテストできるならどこにあってもいいってことなら、それはそれでシンプルな考え方でいいかも。で、実際にそうしてみたら、テストのやり方が煩雑になって、やっぱりどっかにまとめようぜってなりそう。

今日の俺POINT
・基本コントローラーはシンプルに。
・Fat Modelには気をつけよう
・なんでもFatは良くないよ
・Serviceってやり方もあるらしい
・2008年と2009年の記事なんで、今は変わってるかもしれん。

コントローラにたった1つだけあるドクロマークのボタンを押すと、太ったモデルがセクシーに踊りだすという解釈でいいであろうと思われる。

[cakePHP] MVC設計ってまだ把握できとらん…

CakePHPを使ったMVC設計のベストプラクティスを読んで、一度読んだだけではなにがどうなったのかよくわからんかったので、自分なりにまとめてみた。


■コントローラーが変更された点
・共通したorder指定を抜き出してモデル側で設定
・データを取得して表示するという流れは同じなので、アクションを1つにまとめた
・件数指定部分をモーフィングっぽく配列に格納
・モデルにオプションを渡して取得できるようになった
・渡されたパラメーターによって自動で処理が変わるようになった


■モデル
・並び順のデフォルト設定追加
・人気順で取得する機能追加
・特定の設定はモデル側でもっとく

■要点
・MVCではモデルが一番大事
・コントローラーはモデルとビューをつなぐシンプルな糊

・モデルに置けるものはモデルに置く
・ビジネスモデルと連携しないもの(セッション管理・リクエスト、レスポンス処理・セキュリティ、アクセス制限関連)はコントローラーに置く。(それ以外は全部モデルに置く)

参考
CakePHPを使ったMVC設計のベストプラクティス

[symfony] コントローラー内で共通の処理をまとめる

symfonyのコントローラーにはpreExecute()とpostExecute()というメソッドがある。
preExecuteはexecute～の前に、postExecuteはexecute～の後に処理が行われる。
ここに処理を書けば、コントローラー内のアクションに共通の処理を行える

public function preExecute()
{
  parent::preExecute();


  //やりたい処理
}

共通でやりたい処理をどこかにまとめとく機能もたぶんあるよね。cakePHPのビヘイビアみたいなやつとか