Laravelの認証/認可。Auth,Gate,Policyの再整理

by codechord. 0 Comments

アドベントカレンダーに触発されて、記事を書いたところ、ちょうど枠に空きが出たので、投稿したいと思います。

Laravelのドキュメントって結構分かりやすく書かれている方だと自分は思っているんですけど、今日はその中でもこんがらがりがちな「認証と認可」について今一度、整理したいと思います。どういうケースに使えるのかとか。
なお、「認証」の方はartisan make:authしたら概ね完成しちゃいますが、認可って便利なので、認可の説明が多いです。

実世界に置き換えて考える

技術的な話に入る前に、日本語の「認証と認可」を理解します。というのも、「認証と認可」という日本語もわからないし、英語の「Authentication、Authorization」もわからないので。。。言語って難しいですね。。。

ググって見ると、「認証と認可」について、「よくわかる認証と認可 | DevelopersIO」という素晴らしい記事がありました、ここを読めば、理解できます。さすがです、クラスメソッドさん。
一部、抜粋させていただきます。

  • 認証:通信の相手が誰(何)であるかを確認すること。(例:マイナンバーカード)
  • 認可:とある特定の条件に対して、リソースアクセスの権限を与えること。(例:チケット/切符の発行)

切符を買った人は電車に乗るということを許可されますけど、それが誰だって構わない。切符さえ持っていれば、誰だって乗れると。それが「認可」です。

後述していますが今回、認可の実例として、運転免許を例にしています。

「運転免許証」を持つこと自体は、あなたが誰かを確認できるものになるから「認証」を意味しますけど、「運転」という行為は、免許証持っていても飲酒してたらしてはいけませんよね。
もう一つ別の例としては、教習所で試験に合格すれば、運転免許証を発行されますが、交通違反を取り締まっている警察官は、免許の点数を操作することはできますが、免許証を発行処理はできないです。この辺が認可されていたり・されなかったりの話です。

なんとなく理解できたのではないかということで、いよいよLaravelについての話に移ります。

Laravelでは、認証が「Guard」、認可が「Gate/Policy」の3パターンありますので、順にそれぞれ触れていきます。

続きを読む »

brew upgradeの後、phpenvがicu4cでエラーになる際の対処法

by codechord. 0 Comments

8時間費やした。。。。。他の人がはまらないように、記載しておきます。

もともとYarnを使っていて、「brew upgrade」してください。的なメッセージが出てきたので、何気なく、それに従っただけ。

長い間「brew upgrade」していなかったからかよくわからないけど、まさかのPHPが動かなくなった。

エラー内容と原因

このようなメッセージ。

$ php -v
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.61.dylib
  Referenced from: /Users/<USER_NAME>/.anyenv/envs/phpenv/versions/7.2.5/bin/php
  Reason: image not found
Abort trap: 6

普段使っているPHPは、brewで入れたものではなくて、「phpenv global」を指定していたやつだし、もともとYarnのアップデートのためにやったものだから、PHPに影響が行くとは全く思っていなかった。。。

続きを読む »

Webpack使うならLaravel Mixでラクをする

by codechord. 0 Comments

cssを書くとき、sass/scssを書きたくなる。
javascriptを書くとき、babelを使う必要が出てくる。
そんな時、おそらくGulpかWebpack、を使うことを強いられる。

最近は、フロントエンドの開発環境にWebpackを使うことが増えてきたけど、
そんな時は、Laravel Mixを使うとすごく便利。という話。

自分は、Laravel MixというWebpackのラッパーを使って楽している。
Reactでも、Vueでも、BabelでもSassでも、PostCSSでも思いつくことは基本的にできる。
Webpackって、設定ファイルを書くのが面倒。Webpackの設定ファイルはカオスになる。それをうまい事隠してくれる。

個人的に、過去、Gulp -> Webpack -> Laravel Mixと試してきて、ふと、Webpackに戻ろうかと思ったけど、結局Laravel Mixに戻ってきた。
(Gulpだけで良い時もあるので、適材適所)

本記事ではこれらを比較して見た記事。

続きを読む »

Laravel SocialiteのTwitterで認証画面を強制的にだしてみる

by codechord. 0 Comments

表題の通りなんですけど、一度ログインした後、別のアカウントに切り替えようとログインしなおしても、Twitter側にセッションが残っているかなんかで、ログイン画面が出ずにcallbackしてしまう、もしくは今ログイン中のアカウントと紐づくみたい挙動になる。私は毎回ログイン画面出したいんだ!とそういったケース。

なお、Twitterドキュメントを見る限り`force_login=true`してあげれば済む話なんだけど、LaravelのSocialiteでどうするの?という話と、ちょっとおまけ。

続きを読む »

[PHP] Facebook APIのOauthのエラー解決「URLを読み込めません」「Can’t Load URL」

by codechord. 1 Comment

FacebookのAPIを使おうとOauth周りの処理に公式のPHP SDKのライブラリ(v5系)を利用している前提での話です。
(※2016年冬期の記事です。)
https://github.com/facebook/php-graph-sdk

本SDKライブラリを利用して、Facebook APIでOauth認証しようとする際、特定のサーバの環境下で、正式にApp登録をしているにもかかわらず、
下記のようなエラーがでる時があります。すごくはまりましたので、メモとして残します。(自分の場合はさくらのレンタルサーバでした。)

続きを読む »

gulp不要。Browsersyncで2行のLiveReloadみたいな環境

by codechord. 0 Comments

browesersync

Advent calenderの時期というわけで、フロントエンドエンジニアAdventCalenderの5日目久しぶりに更新です。

主にフロントエンドのデバッグの話で、色々作業していくときに、LiveReloadを使うと非常に効率が良い。保存と同時にブラウザ再読み込み☆

で、ブラウザの自動更新の環境を作る際には、GulpとBrowserSyncを使ったりReactなんかのWebpack/Hot Moduleを使うという方法をよく見かける気がしますが、
ここではブラウザの自動更新の機能のためだけにGulpしてるとか、逆にnode_modulesのフォルダがうっとおしいから、Gulpしたくなくてをライブリロードを断念している人に向けて、ターミナルとbrowsersyncコマンドだけでシンプルに解決してみたいと思います。(何かしらフレームワーク使ってる場合は、そのフレームワークでのベストプラクティスが案内されているのでそれを利用するといいと思います。)

結局GulpをつかったとしてもBrowserSyncのラッパーみたいな感じなので、それCLIだけでできるよって。

というわけで、Gulpを使わずにターミナルだけで今すぐ使える、簡易のライブリロードみたいなブラウザの自動再読込の環境を作ってみよう。

続きを読む »

VelocityとPixiの手抜きアニメーション。こうして花を咲かせましょう

by codechord. 1 Comment

160220

この記事は「[JS/CSS/SVG] Webとアニメーションの様々なありかた」という勉強会用の発表資料です。
アニメーションまわりのプラグインを紹介したものの、すごく駆け足だったので、あらためて、ご紹介します。

なお、ここで紹介するサンプルのデモは、githubにソース置いておきます。
(スライド無いです)

続きを読む »

Aura:FilterとFormでValidation

by codechord. 0 Comments

ちょっとしたAjax系のFormの実装をする必要があって、
一枚ペラっと作ってもイイんだけど、せっかくだし今風に作ってみようと思い、Auraに手を出した。

Formのためだけに、Wordpress使うのもなんだし、LaravelやSymfony使うのもFatすぎるかなって感じていて。
Auraはフルスタックのフレームワークではなく、必要なComponentをとっつけて組み立てるという感じ。

理解の仕方は、次の順
日本語ドキュメントがあるので、ざっくりはわかる。
・一つ一つのComponentが軽量でソースを追っかけるのも比較的簡単。
・同様に、それぞれがのReadmeドキュメントが整ってる印象。

https://github.com/auraphp
https://github.com/friendsofaura
今回サンプルとして、htmlのフォームでPOSTした内容をバリデーションチェック加えて、json形式で何らか返すというものを
以下の2パターンで作った。それぞれは同じ結果を返す。

・A: Filterをaura/filterを直接使う。(github)
・B: aura/input/Formの継承クラスを作成し、Form内でfilterを行う。(github)

基本

/vendor/auraの中身で、重要そうなのは、web-kernelあたりのよう。
ここでrouter、dispatcher、あとwebコンポーネントにある、RequestとResponseとかが、定義される感じ。

アプリケーションは、/config/Common.phpにかいていく。なお、/config/_env.phpにて、環境の設定を変更をすることで、

  • /config/Dev.php
  • /config/Prod.php
  • /config/Test.php

と、環境別に動作を切り替えれることが出来る。/config/Common.phpは、_env.phpの設定にかかわらず全てにおいて実行される。

DI

関連するサービスをsetし、必要時に、getして使う。

 $di->set(<サービス名>,$di->lazyNew());
 $service = $di->get(<サービス名>);

ルーティングとディスパッチャ

$router->add()でルーティングを指定して、$dispatcher->setObject()のクロージャで、ルーティングの処理をする。

$router->add(, );
$dispatcher->setObject(, function () use ($di) {
  // ここに処理
});

バリデーションチェック

Aura/Filterを追加する必要がある。Aura/inputも。必要に応じてAura/htmlも追加。

  • HTMLテンプレート書くなら、次のバンドルをcomposerに追加する。
    composer require foa/html-view-bundle
  • フォーム書くなら、次のバンドルをcomposerに追加する。
    composer require foa/filter-input-bundle

さて、説明がうまく出来ないので、以下のA、Bの場合とで、サンプルソースを見比べて欲しい。
/form.htmlの静的フォームから/sendにPOST送信され、フィルタのかけ、Jsonを返すのだが、Bの場合だけDIを使った形となっている。

A:Filterだけの場合
https://github.com/tomothumb/Sample-Aula-validation/blob/5e8dd23b450140ab4f2fe55ac7a0b399dc2bedb3/config/Common.php
Dispacharの中に書いていく。

B: Fromを利用する場合
https://github.com/tomothumb/Sample-Aula-validation/blob/master/config/Common.php
/src/App/From/Contact.phpを追加し、Formの要素とバリデーションの内容を記述する。

違いをGistに書いた。(わかりにくい。。。)

設計方法学ぼうとおもってたのに、いつのまにか、アプリケーションの書き方/使い方を学んでいる自分がいる。。。

同じことをSilexとSlimでも今度やってみよう。

ECCUBE3とSymfonyとSilexの歩き方

by codechord. 0 Comments

Photo-12-12-15,-12-06-20-AM

日付変わっちゃいました・・・
2015年ECCUBE アドベントカレンダー23日目の記事です。写真はECCUBE開発合宿の深夜の1コマ。

当初、作ったプラグインの案内でもしようかと思ったのですが、バグだらけで改善作業中なので、自分がECcubeを理解していく中で(まだまだわかってないですが)、自分なりのベストプラクティスを、これからECCUBEの開発を始めるヒトに向けて共有したいと思います。
ちなみに、バグだらけのプラグインはgithubベースでメンテするというか、メンテフリーで行く予定なので、自由にパクって下さい。
ECCUBE3-InfiniteScroll」「MECCUBE3-Masonry」「ECCUBE3-Loveit」(3つありますが、内容似てまして、松竹梅的な。)

思ってたのとなんか違う。

まず、私個人としては、Laravelは半年弱ほど触った程度。
LaravelはSymfonyベース、ECCUBEはSilexベース、そのSilexはSymfonyベース、だからきっとなんとなくわかるはずと思ってたんですが、いざ蓋を開けてみると、「これ、思ってたんと違う。。」というのが正直な感想。

Symfonyを理解していないからか?と、そう考え、ECCUBEの開発合宿へ参加したついでに、たまたまその翌日、東京はメルカリさんで開かれたsymfony meetupに寄ってきました。
つい先日、待望のsymfony本「基本からしっかり学ぶ Symfony2入門」の出版されたけども、その著者が登壇されるということだったので、行かなきゃとい思いまして、毎度のことながらスケジュールつめこんで。

Symfonyを学ぶことは近道。

ECCUBEを始め、最近は著名なCMSやフレームワークがこぞってSymfonyを採用しはじめていますが、なぜSymfonyが選ばれるか。なぜSymfonyが王道なのか。そういった内容を話されていました。(そのスライドはこちら⇒ Symfonyを選ぶ理由とその他の話 )

CakePHPでも、Laravelでも、それぞれのフレームワークでCakePHP Way、Laravel Wayみたいな◯◯Wayというベストプラクティスや強い主張があったりするけど、Symfonyというのは、主張してこないフレームワークであると。自分流にアレンジしやすいとのこと。

主張してこないとはどういうことかというと、Symfonyのコアが担うのは、
「リクエストを受け取り⇒レスポンスを返す」
というところ。つまりは、Webアプリケーションの根本的な所を学ぶことができると。

王道を知ることは、今後他のフレームワークを理解するうえでも、それぞれの◯◯ Wayの解釈ができるようになりますよ、とそういった内容でした。

(※ちなみに、Symfonyの日本語ドキュメントのサイトは遅れているようで、翻訳ついていくのは諦め気味とおっしゃっておられました。)

Symfonyの基礎をわかるとどうなる?

symfony本「基本からしっかり学ぶ Symfony2入門」全300Pぐらいで、早速ですが簡単な所は読みました。初期の構想から発売まで二年半ぐらいとおっしゃっておられたような。書籍の構成としては、

  • フレームワークとはなんぞや
  • Symfonyとはなんぞや。
  • デバッグバーの使い方
  • Routing
  • Controller
  • View (Twig)
  • Entity (Doctrine)
  • Repository
  • Form
  • Validation
  • メール(Swiftmail)
  • 機能の拡張
  • フィクスチャ
  • Console拡張
  • API実装
  • サービスプロバイダ
  • テスト

が順に解りやすく落とし込まれてあり、読み進め、実際に手を動かしながら、一つのWEBアプリケーションができます。Symfonyの基礎が中盤ぐらいまででわかります。後半で、サービスプロバイダの解説がされてありますが、ここを理解することがSymfonyおじさんになる手段であり、みながSymfonyを採用する肝のようです。ここまで読みきれてません、まぁ正直難しいです。

ECCUBEおじさんになるためには

先に述べたとおり、基本的な所を読了するだけで、ECCUBEのディレクトリ構造がざっくり理解できるようになります。
するとまぁ、ECCUBEとSymfonyとの違いがなんとなくわかりはじめます。

Symfonyは個性を主張してこないと述べましたが、Symfonyのチュートリアル的なものをしていると、アノテーションとか、手軽だけど、なんか魔法ばっかり。思っきり個性を主張してきます。。。(目をつぶります)

このせいで、Doctrineでもフォームでも何でも、ECCubeが吐くエラーメッセージの解決策をググりますと、概ね、Stack Overflow様がSymfonyの解決するための黒魔法を教えてきます。ECCUBEではこの魔法が全く役に立たずハマります。

そこで、Symfony本に目を通しておきますと、ホグワーツ魔法学校に通ったようなものですから、この先生の言ってることは、こう読み替えればよいのかとか、Silexの領域だなとか、ほんの少し見えてくるようになります。
で、最後にSilexやDoctrine、Symfonyのドキュメンテーションへと理解を深めていく旅に始まります。

Silexにどっぷりは必要?

おそらく、ECCUBEを深く知る上では、

  • Symfonyの基礎を把握する
    ⇒必要に応じてSilexのドキュメントを見る

という流れではありますが、Silexのドキュメントもなかなかしんどいです。
ECサイト作成程度の話であれば、Silexには触れず、

  • Symfonyの基礎を把握する
    ⇒ECCUBEのコアのコードからパクる。
    ⇒必要に応じてSilexのドキュメント

というのがベスト・プラクティスじゃないかなと思っています。といいますのも、Symfony基礎がわかるとディレクトリ構造がわかるので、コードのたどり方がなんとなくわかってきて、ECCUBEコアに、ピンポイントで似た例がでてくるのがほとんど。Silexのドキュメント見るより手っ取り早いと感じるからです。

コア開発者になるなら、SilexもSymfonyサービスプロバイダもしっかり理解してください。ということになるんだと思います。

さいごに

ECcubeの話というより、Symfonyの話がほとんどになってしまいました。
最後になりますが、ECCUBEはSilexベースですが、Symfonyかじらず、いきなりSilexから入っちゃうと遠回りになると思うので。まずは王道からと、オススメしつつ、アドベントカレンダーをバトンタッチしたいと思います。

最後になりますが、Symfonyを初学者向けソースを、Symfony meetupで知った部分貼っていきます。
参考になれば幸いです。

YAPC::Asia Tokyo 2015に参加した覚え書き #yapcasia

by codechord. 0 Comments

yapc

ブログを書くまでがYAPCというわけで、聞いたことを忘れないうちに、一応書こうと思う。考察や見解をいれてない、ただの議事録記事ですが。

さて、Webの歴史をつくってきた貴重なカンファレンス。
本年度で10年の幕を終えるというわけですが、遠いということもありましたけど、Perlの親だったり、Rubyの親だったりをはじめ、Rebuild.fmやMozaic.fmの人だったり、Github,Google,サイボウズ、KAIZEN、DeNA、クックパッド、KAYAC、はてななどなど、まー、いろいろと中の人達の活動を見れるすごくいい機会というわけで、迷わず参加。
2000人オーバーしたみたいです、すばらしい。注目度が高いイベントは例外なく内容が濃い。

偏ってるけど、個人的に注目したテーマが、

  • ES6、Node
  • HTTP/2
  • Electron
  • WebAudio

ってところ。インフラ周りも聞いたけど、一番近いところがやっぱり興味がわくものですね。
あとはDeepLearningとかもフォローアップしたいところだったけど、見れなかった。

さて、印象に残ったセッションをメモしていきます。

続きを読む »