2018-12-16

Laravel Mixというかwebpackでconsole.log()が消えないようにする

追記

Laravel Mixとwebpackのどっちが犯人なのか探ってたら、Laravel Mixが犯人であること、さらにじつはもうdrop_consoleがデフォルトで無効になっていることに気付いた。

Remove drop_console option · JeffreyWay/laravel-mix@a9d2646 · GitHub

ということでこの記事にはもうなんの意味もない……。

追記終わり。

Laravel Mixが使っているwebpackが使っているUglifyJSにはdrop_consoleというオプションがあり、これが有効だとconsole.log()が消される。

アホなオプションなのでUglifyJSではデフォルトは無効のようだが、Laravel Mixかwebpackか知らんがどちらかでデフォルトで有効になっている。

こんなものはバグの温床でしかないので無効化したい。

以前までは、

mix.options({
    uglify: {
        compress: {
            drop_console: false
        }
    }
});

で行けたけど、(多分)uglifyjs-webpack-pluginが1.0になるあたりの変更で仕様が変わって、

mix.options({
    uglifyOptions: {
        compress: {
            drop_console: false
        }
    }
});

にしないとエラーになるようになった。

なお以下のようなエラーが出てた。

ValidationError: UglifyJs Plugin Invalid Options

options['compress'] is an invalid additional property

2018-12-12

Laravel 5.6.27以降でログアウト後のリダイレクト先を変更したいなら、logout()ではなくloggedOut()をオーバーライドする

Laravel Laravel 5.7

5.7で開発中なんだが、ログアウト後のリダイレクト先を変更するのどうしたらいいか調べてたら、ソースコードを読む感じIlluminate\Foundation\Auth\AuthenticatesUsersのloggedOut()をオーバーライドするのがよさそうだったのだが、ググると同じクラスのlogout()をオーバーライドする例ばかり出てくる。

なぜかなーとgit blameしたところ、割と最近実装されたメソッドのようで、そのせいだろう。

Update AuthenticatesUsers.php · laravel/framework@e4a00e8 · GitHub

ということで、5.6.27以降ならloggedOut()が使えるので使おう。

<?php
# ...
class LoginController extends Controller
{
    use AuthenticatesUsers;
    # ...
    protected function loggedOut(Request $request)
    {
        return redirect(route('my_login'));
    }
    # ...
}

とかそんな感じでよさそう。

認証周りのカスタマイズの知見いろいろ溜まってきているので、そろそろ一回まとめたいなー。

2018-12-09

LaravelのAuth::routes()で一部機能(ルート)を無効にする

Laravel Laravel 5.7

Auth::routes()の本体である、Illuminate\Routing\Router::auth()を確認してて気付いたのでメモ。

<?php
# ...
Auth::routes([
    'register' => false,
    'reset'    => false,
]);
# ...

これで新規登録とパスワードリセットが無効にできる。管理者だけが扱うようなアプリケーションでは使いそう。

まあ、ドキュメントに書いてある。

また、登録時のメールアドレスの確認を有効にするには、

<?php
# ...
Auth::routes([
    'verify' => true,
]);
# ...

5.7からの機能っぽい。まあこれもドキュメントに書いてある。

なおルートの設定だけでは駄目っぽいので注意。

2018-12-06

Composerのディレクトリが~/.config/composer以下になる場合

PHP Laravel

CentOS 7環境で、新規案件のためにLaravel入れたのだがlaravelコマンドが入ってない。~/.composer/vendor/binにパスは通ってるのになあ、とよく見てみると、~/.composer/vendor/bin自体がなかった。

もうちょっと調べてみると、~/.config/composerというのがある。どうも~/.composerではなくこちらにインストールされているようだ。

また、Laravelのドキュメントに以下のようなことが書いてあった。

グローバルなComposerのbinディレクトリを$PATHへ登録してください。このディレクトリはオペレーティングシステムにより場所が異なります。通常は、以下の場所です。

macOS: $HOME/.composer/vendor/bin

GNU／Linuxディストリビューション: $HOME/.config/composer/vendor/bin

でも今まで同じ設定で動いてたしおかしいな、最近変更あったのかなとComposerのリポジトリ調べてみる。どうもこの辺で設定されている模様。

XDGがどうこうだとディレクトリが変わるらしい。さっそく環境変数をチェックしてみると、今まで使っていた環境(の一部、確認したのは)ではXDG_*という環境変数はなく、しかし今回の環境ではXDG_RUNTIME_DIR, XDG_SESSION_IDと2つ設定されいた。

どうもこれが原因のようだ。しかしこのXDGというのはそもそもなんなのか？　そしてなぜ今まで設定されていなかったのに、今回設定されているのか？

後者の疑問はまだ解決していないが、前者については解決した。ArchLinuxのWikiに詳しい情報があるが、freedesktop関係の、ユーザディレクトリ内のディレクトリ構成の規格関係らしい。そういえばなんとなく聞き覚えがあるような。

解決策として、生のパスを入れるのではなく、Composerを叩いてパスを教えてもらうことにした。

export PATH=$(composer config --global --absolute home)/vendor/bin:$PATH

2018-12-05

GitHubの公開鍵が勝手に消えていた件

セキュリティその他

Ansibleのauthorized_keyでGitHubの自分の公開鍵を指定するみたいな使い方してたので気付いたんだけど、昨日、登録していた公開鍵(1つ中1つ)が消えていたっぽい。

身に覚えはなく、ブラウザ履歴や作業ログで消えた時間帯を確認してみても、やっぱりその時間帯にはGitHubにアクセスしてすらいない。

となるとアカウント情報漏れでもしたかな、となるが、MFAこそかけてないもののパスワードは使い回さないし、それも考えにくい。

一応GitHubのSecurity historyを確認してみると、いくつかのログインと、問題の公開鍵の削除、ほかには慌てて再追加した際のログだけ残っていた。

f:id:xxmagai:20181205153238p:plain — GitHubのSecurityページ

ログインに関してはすべて自分のログインでほぼ確定。

さらに、ほかのログにはIPアドレスなどが記録されているのだが、公開鍵の削除については記録されていない。

f:id:xxmagai:20181205153242p:plain — public_key.createのログ

f:id:xxmagai:20181205153408p:plain — public_key.deleteのログ

もう一つ、この公開鍵を登録したのは、削除された日時のほぼ丸一年前である。

ググってもそんな情報はなかったが、おそらく未使用のまま一年経った公開鍵は削除される、とかそういう機能がこっそりあるのではないかという結論に達した。

追記: なにかの参考になるのかもしれないので、同じ現象っぽいものメモ

githubで見に覚えのないpublic_key.deleteが記録されていて困惑している。ssh keyの登録は記憶にある通りなのだけれど。
— Yasushi Abe (@yasushia) October 29, 2018

So about a month ago one of my public keys was removed..

Chat Log Server / Message 133053 in #github

追記2: 手動で削除した場合もIPアドレスは記録されないらしい

ちなみに自分で削除したときもIPアドレスは記録されませんでした。
— Yasushi Abe (@yasushia) 2018年12月5日

追記3: 一年で消えていた人がもう一人確認されたので、この結論でそれなりに正しそう

ピンときたのでメールを検索してみたら、deleteの1年と1日前にA new public key was added to your account のメールがありました。
1年で勝手に削除っぽいですね。ありがとうございます。すっきりしましたw
— Yasushi Abe (@yasushia) December 5, 2018

2018-12-05

Vagrant + VirtualBox + vagrant-vbguestでCentOSでGuestAdditionsがうまく入らない場合

Vagrant Windows

雑な記事注意。

Please install the Linux kernel "header" files matching the current kernel
for adding new hardware support to the system.
The distribution packages containing the headers are probably:
    kernel-devel kernel-devel-3.10.0-862.14.4.el7.x86_64
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel modules.  This may take a
 while.

This system is currently not set up to build kernel modules.
Please install the Linux kernel "header" files matching the current kernel
for adding new hardware support to the system.
The distribution packages containing the headers are probably:
    kernel-devel kernel-devel-3.10.0-862.14.4.el7.x86_64
An error occurred during installation of VirtualBox Guest Additions 5.2.22. Some functionality may n
ot work as intended.
In most cases it is OK that the "Window System drivers" installation failed.
Redirecting to /bin/systemctl start vboxadd.service
Job for vboxadd.service failed because the control process exited with error code. See "systemctl st
atus vboxadd.service" and "journalctl -xe" for details.

こんな感じのログ出てたら、見るべきは一行目。

[vagrant@localhost ~]$ yum list installed | grep kernel
kernel.x86_64                    3.10.0-862.14.4.el7            @koji-override-1
kernel-headers.x86_64            3.10.0-957.1.3.el7             @updates
kernel-tools.x86_64              3.10.0-862.14.4.el7            @koji-override-1
kernel-tools-libs.x86_64         3.10.0-862.14.4.el7            @koji-override-1

多分こんな感じになってるので、

sudo yum update kernel

https://github.com/dotless-de/vagrant-vbguest/issues/311

確認してないけど、

kernel-devel-`uname -r`

https://github.com/dotless-de/vagrant-vbguest/blob/c0e47b9cb4e8936d270e952668aef78ac2d6e4e8/lib/vagrant-vbguest/installers/redhat.rb#L24

これがよくないのかな。

2018-11-27

フリーランスのプログラマにはどの業種扱いで個人事業税がかかるのか

その他

数年前から個人事業税取られてるんだけど、プログラマって個人事業税の対象にあたらないよね？　法定業種のうちに該当するのないよね？　ってずっと思ってたんで、今回ちょっと調べてみた。

適当にググった感じだと、やれコンサルタント業にあたるだの、デザインやってるならデザイン業にあたるだのといった話があったが根拠に欠けて参考にならない。デザインやってないし、コンサルタントと言うのもだいぶ無理がある。そもそもコンサルタントにあたるとして、コンサルタントの定義ってどこの法律でされてるんだ？　みたいのもあるし。

結論から言うと、「請負業」扱いで取られていた。県税事務所にも確認したので、俺のケースに関しては確定っぽい。

じっさいほぼ準委任でなく請負で仕事してるので、まあ「請負業」なのかなあと。

で、問題は根拠だ。

まず個人事業税自体だが、これは地方税法で定義されているようだ。

個人の事業税に係る課税標準及び税率等

ただしここでは課税対象者については書かれていない。事業税の通則の方にある。

３　個人の行う事業に対する事業税は、個人の行う第一種事業、第二種事業及び第三種事業に対し、所得を課税標準として事務所又は事業所所在の道府県において、その個人に課する。

第七十二条の二

そしてその下の方に、対象の事業についてのリストがあるのだが、ここにあるのが完全にリストだけなのである。ここでは、

十四　請負業

とだけしか書かれていない。請負業とはなにを指すのかが定義されていない。

いろいろ探したが、請負業の定義はなさそうである。一応ある程度近そうなのが、法人税法施行令の中の以下の部分だが、これだけでは有効とはいえないだろう。

十　請負業（事務処理の委託を受ける業を含む。）のうち次に掲げるもの以外のもの

http://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/viewContents?lawId=340CO0000000097#179

請負業のうち、もなにも、請負業がなんなんだって話なのだが、どう調べても請負業の定義が出てこなかった。多分決まっていないのだろう。本当に適当な話だ。