普通はマニュアルどおりにやるだけで構築できるんですが、Laravel Native なアプリケーションでない場合、テーブル名やカラム名が違って単純にいきません。そんな場合の対応を残しておきます。
Laravel 5.5、Laravel Passport 4.0 で試しました。あんまり深掘りしてないので適当書いてるかもしれません。

前提

DBマイグレーションで生成される oauth_* テーブルはそのまま使います。

テーブル名が users じゃない場合

User クラスに $table プロパティをセットすればよいです。Eloquentの仕様ですね。

protected $table = 'user'; // テーブル名が user の場合

プライマリキーのカラム名が id じゃない場合

Eloquent 的には User クラスに $primaryKey をセットすればいいんですが、Laravel Passport には getAuthIdentifirName メソッドをオーバーライドする必要があります。
getAuthIdentifirName は Authenticatable インターフェースにあるメソッドです。
認証 5.3 Laravel

public function getAuthIdentifierName()
{
    return 'user_id'; // プライマリキーが user_id の場合
}

ユーザ名のカラム名が username じゃない場合

User クラスで findForPassport メソッドをオーバライドします。
引数 $username に入力されたユーザ名がセットされるので、User モデルの検索条件を調整してレコードを返却すればOKです。

public function findForPassport($username)
{
    return $this->where('user_name', $username)->first(); // カラム名が user_name の場合
}

パスワードのカラム名がpasswordじゃない・独自の保存形式の場合

User クラスで validateForPassportPasswordGrant() メソッドをオーバライドします。
引数 $password に入力されたパスワードがセットされるので、User モデルのパスワード情報と比較すればOKです。

public function validateForPassportPasswordGrant($password)
{
    return $password === $this->pass; // カラム名がpass かつ 平文保存（！）の場合
}

注意

Laravel Passport の Laravel/Passport/Bridge/UserRepository.php にある getUserEntityByUserCredentials() の実装から類推しました。
文章化されている仕様かどうかは確認していません。

2017-01-08

ポッピンQネタバレ感想 - クソガールのための物語

映画

この文章は、2016年12月23日に公開された劇場用アニメ映画「ポッピンQ」について感じたことを書いたものです。どうしても本編を視聴した上での感想になりますので、ネタバレを忌避される方はお気をつけください。

2016-03-21

RHEL7/CentOS7でsyslogを全て出力するにはどうするか

RHEL7/CentOS7 では、御存知の通りsystemdが導入されています。この影響でログ関連も大きく構成が変わっています。まぁまずマニュアルの18章を読みましょうね。
第18章ログファイルの表示と管理

とりあえず、標準構成ではだいたい以下のフローで動くと思っていれば特に問題ないと思います。

全ての Syslog メッセージはまず journald にキャッチされ、構造化された Journal データとして保持される。
rsyslogd は、imjournal モジュールを利用して journald から必要なログを取得し、/var/log/messages や /var/log/maillog などに出力して永続化する。

ただ、標準設定のままだと困ったことがあって、上記の1と2の両方でログの流量制限が施されています。システムの保護という点ではよいのですが、デフォルトは結構キツめの制限なので、メールログなんかは割りとすぐ上限に達してしまいます。必要に応じて緩和しましょう。

journald の制限

journald の制限は、RateLimitInterval と RateLimitBurst によって決まります。以下、man journald.conf より。

journald.conf

RateLimitInterval=, RateLimitBurst=

Configures the rate limiting that is applied to all messages generated on the system. If, in the time interval defined by RateLimitInterval=, more messages than specified in RateLimitBurst= are logged by a service, all further messages within the interval are dropped until the interval is over. A message about the number of dropped messages is generated. This rate limiting is applied per-service, so that two services which log do not interfere with each other's limits. Defaults to 1000 messages in 30s. The time specification for RateLimitInterval= may be specified in the following units: "s", "min", "h", "ms", "us".
To turn off any kind of rate limiting, set either value to 0.

RateLimitInterval で指定した期間に RateLimitBurst を超える量のメッセージがあると破棄されます。デフォルトでは30秒あたり1,000メッセージ*1に制限されています。破棄されたメッセージの数は Journal には記録されており、 journalctl コマンドで確認することができます。必要なログの量を見積もって、適切な値を設定しましょう。
なお、いずれかの値を0にすると、破棄せず無制限に記録するようになるようです。よくわかんないのであれば無制限にしておけばいいのではないでしょうか。（投げやり）

rsyslogd の制限

rsyslog の制限は、$imjournalRatelimitInterval と $imjournalRatelimitBurst で決まります。以下、RedHatのドキュメントより。

18.6. Rsyslog での構造化ロギング
Journal から Rsyslog にデータをインポートするには、/etc/rsyslog.conf で以下の設定を使用します。
$ModLoad imjournal

$imjournalPersistStateInterval number_of_messages
$imjournalStateFile path
$imjournalRatelimitInterval seconds
$imjournalRatelimitBurst burst_number
$ImjournalIgnorePreviousMessages off/on
（中略）
seconds では、レート制限の間隔を設定します。この間隔内に処理されるメッセージ数は、burst_number で指定して値を超えることはできません。デフォルト設定は、600 秒あたり 20,000 メッセージです。Rsyslog は、この指定された時間枠内で最大バースト後に届いたメッセージを破棄します。

だいたい書いてあるとおりで、考え方は journald と同じです。rsyslog のマニュアルによれば、$imjournalRatelimitInterval を 0 にした場合は無制限になるようです。よくわかんないのであれば無制限にしておけばよいのではないでしょうか。（投げやり）

imjournal: Systemd Journal Input Module — rsyslog v7-stable documentation

ratelimit.interval seconds (default: 600)

Specifies the interval in seconds onto which rate-limiting is to be applied. If more than ratelimit.burst messages are read during that interval, further messages up to the end of the interval are discarded. The number of messages discarded is emitted at the end of the interval (if there were any discards). Setting this to value zero turns off ratelimiting. Note that it is not recommended to turn of ratelimiting, except that you know for sure journal database entries will never be corrupted. Without ratelimiting, a corrupted systemd journal database may cause a kind of denial of service (we are stressing this point as multiple users have reported us such problems with the journal database - - information current as of June 2013).

-ratelimit.burst messages (default: 20000)

Specifies the maximum number of messages that can be emitted within the ratelimit.interval interval. For futher information, see description there.

その他

なんらかの理由でレガシーな syslogd を使う場合は、journald の ForwardToSyslog オプションを使って、journald がキャッチした Syslog メッセージを更に他の syslogd に転送する必要があります。このオプション、7.0/7.1ではデフォルトで有効になっているのですが、7.2で一旦無効化されている*2 *3ので、この場合は journald.conf を編集して有効にする必要があります。

ForwardToSyslog=yes

ただし、ForwardToSyslog での転送は失敗することがあります。この場合も Journal には失敗したメッセージ数が記録されます。この辺りになると RedHat のサポート範囲外でもあるので、RHEL7/CentOS7 では、あまりレガシーな syslogd に拘らないほうがいいような気がします。

*1:systemd のバージョンによって異なる可能性がありますので、システムの man journald.conf をご参照ください

*2:システム負荷の懸念から systemd 216 で無効化され、これ以降のパッケージをインストールしている場合は影響を受けます。ただ、その後 219.20 でRHEL向けには再度有効化されたので、将来的にはまた有効になりそうです。

*3:Bug 1285642 – journald.conf - changed default for ForwardToSyslog parameter

2015-10-25

家庭用小型結束機しめしめ45-IIは神である

生活

www.nirei.co.jp

しめしめ45IIとは仁礼（ニレイ）工業株式会社家庭用小型結束機である。商品説明にそう書かれている。神ではない。
だがしかし、雑誌やダンボールを相手にビニールテープやハサミを持って悪戦苦闘するあの責め苦から、しめしめ45IIはその身ひとつで救済してくれる。神である。
おそらくすでに世界中に信徒はいるはずだが、あまり布教活動を見かけたことがないので布教したい。

見た目は複雑そうな神だが、基本的な使い方は以下の流れになる。

先端に装填されているクリップ穴を通しながらベルトを引き出し、結束したいものに巻きつける。
巻きつけたベルトをクリップに戻して固定し、余ったベルトを巻き取る。
クリップの手前にあるカッターでベルトをカットする。

というか公式サイトに説明動画があるのでこっちを見ればよい。事前の準備から説明してくれている。神は慈悲深い。www.nirei.co.jp

クリップにツメ、ベルトにミゾが刻まれているのがポイントで、行きのベルトと戻りのベルトの厚みがクリップ内部で重なると、巻き取り方向にしか引き出せないようになっている、そうして固定したうえで、がっちり締め付けていくという寸法だ。
このしめしめする時の結束感はたまらないものがある。抵抗できないベルトを一方的に巻き取っていくのも気持ちいいが、現行のしめしめ45IIにはベルトを更に巻き取るための増し締めレバーが実装されており、レバーをシュコシュコしながら結束の限界までしめしめすることができる。この気持ちよさは神でなければ経験できない。

とはいえ神にも難点はある。

神からベルトを引き出すときには、ちょっとした慣れが必要である。行きのベルトがクリップのツメにひっかかってしまい、うまく引き出せなくなることがあり、それでも無理に引き出そうとすると、ツメが破損してクリップがひとつおしゃかになってしまう。
説明書に書かれている通り、ミゾのない上向きに引き出すことを意識すれば失敗はしにくくなるのだが、慣れないうちはなかなか難しく、ツメが破損したのに気付かず引き出してしまうことがしばしばあった。
あからじめベルトが上向きに反るようになっていたりと工夫はあるものの、もう少し改善してほしいところである。

とはいえ、こんな難点は慣れで解決できるものだ。信じ続けたものは救われる。
何よりしめしめするのが気持ちいいのでとてもオススメ。

2015-05-30

PHPのDoS脆弱性(CVE-2015-4024)キツくない？

2015/05/14にリリースされたPHP 5.4.41/5.5.25/5.6.9で修正されたDoS 脆弱性がある。

Fixed bug #69364 (PHP Multipart/form-data remote dos Vulnerability). (CVE-2015-4024)

バグレポートに細かい話（原理から再現手順まで）が載ってて、要は細工したリクエストを送るだけで、しばらくCPUリソースを浪費するって話と読み取った。リクエストパラメータをパースする段階で起こるので、脆弱性のあるバージョンのPHPをHTTPサーバ経由で実行できる環境が全て影響を受けるんじゃないかなあ。

数年前に話題になったHashdosと、攻撃のお手軽さも影響も大差はない気がするんだけど、あんまり騒がれていない気がする。なんでなんだろう。
いやまぁHashdosはいろんな処理系に共通してたから話題になったんだろうけど。

PHPのアップデートができない場合、IPSとかWAFとかでそれっぽい通信を弾くとか、Hashdosと同様にPHPのpost_max_size設定かHTTPサーバの設定でリクエストのサイズを制限するとかしかないような気がする。原理からするとinput_max_varsは関係なさそう。

あと一ヶ月くらいバグレポートが放置されてたのがおもしろいと思う。

==2015/06/30 追記==

ディストリの対応を１ヶ月ほどチェックしてたんだけど、Red Hat Enterprise Linuxの一部パッケージは対応されたっぽい。対応するCent OSのリポジトリにもパッチが来ているはず。
access.redhat.com | CVE-2015-4024

RHEL 7 の php パッケージ（5.4系）
RHEL 7 の php55-php パッケージ（5.5系）
RHEL 7 の rh-php56-php パッケージ（5.6系）
RHEL 6 の php55-php パッケージ（5.5系）
RHEL 6 の rh-php56-php パッケージ（5.6系）

RHEL 5 の php パッケージ（5.1系）や RHEL 6 の php パッケージ（5.3系）はまだ脆弱なまま。
っつうか対応する予定あるのかなこれ……。

==2015/07/10 追記==

以下パッケージも対応された。

RHEL 6 の php パッケージ（5.3系）
RHEL 7 の php54-php パッケージ（5.4系）
RHEL 6 の php54-php パッケージ（5.4系）

出張おはき゛ろく

Twitterで書ききれないことを書こうと思います。

とほほのWWW入門トップページの歴史

ワタミの外食事業の離職率は、厚生労働省公表の宿泊業・飲食サービス業の離職率を下回っていた

Laravel PassportでOAuth2サービスプロバイダを後付けした

前提