_notesとdwsync.xml

_notesとdwsync.xmlは?
-> Dreamweaverがファイル同士の同期情報を管理する為のファイル
-> ファイルとGET/PUTするときに双方のタイムスタンプを見比べて、上書きの警告・チェックをする役割を持つ

確かにdwsync.xmlの中身を見ると、数字が入ってますね。ただ、Unixタイムスタンプとは別の値の様です。

local="*" remote="*"

なるほど、面倒だけど、一つ一つ調べるべきだな。

[Laravel8.x] リリース前に特定のipのみログインできる様にする

リリース前にテストを行う場合に、特定のipからのアクセスのみログインできる様にしたい

$request->ip();でipを取得できる

    public function test(Request $request){
        $ip = [
            ['name'=>'a社 事業部', 'ip' => '127.0.0.1'],
            ['name'=>'a社 開発部', 'ip' => '127.0.0.2'],
            ['name'=>'b社', 'ip' => '127.0.0.3'],
            ['name'=>'myIP', 'ip' => '192.168.33.1'],
        ];
        
        $user_ip = $request->ip();
        $detect = collect($ip)->contains('ip', $request->ip());
        dd($detect);
        
        return view('admin.test');
    }

-> true

これをmiddlewareのrole_idの制御しているところで実装する。

    public function handle(Request $request, Closure $next)
    {
        
        
        $user = Auth::user();
        if(!$user->isAdmin()){

            $ip = [
                ['name'=>'a社 事業部', 'ip' => '127.0.0.1'],
                ['name'=>'a社 開発部', 'ip' => '127.0.0.2'],
                ['name'=>'b社', 'ip' => '127.0.0.3'],
                ['name'=>'myIP', 'ip' => '192.168.33.1'],
            ];
            
            $user_ip = $request->ip();
            $detect = collect($ip)->contains('ip', $request->ip());

            if(!$detect){
                Auth::logout();
                return redirect('/login')->withErrors(array('name' => 'ただ今ログインできません。'));    
            }
            return redirect()->intended('/hoge');
        }
        return $next($request);
    }

-> ただ今ログインできません。

なかなかテクニカルになってきた。

[Laravel8.x] bcryptのストレッチングが10以外のパスワードでログインする

まずストレッチング10で”hogehogehoge”をbcryptします。
$2y$10$duXTr3ecMQZQUF6P3HWHWuZzRdZvS5AORbZuCLcID3qjqk1ZZLUja
mysql> update users set password=”$2y$10$duXTr3ecMQZQUF6P3HWHWuZzRdZvS5AORbZuCLcID3qjqk1ZZLUja” where name=”user1″;

これでログインします。

はい、当然ログインできます。
続いて、ストレッチングを12に上げます。
$2y$12$DM/DSh2iH9SYRYXHZRlIpuGvIUjBiehKuAuoGhq4cnCrQ.SZbc/Fa
mysql> update users set password=”$2y$12$DM/DSh2iH9SYRYXHZRlIpuGvIUjBiehKuAuoGhq4cnCrQ.SZbc/Fa” where name=”user1″;

あ、round12でもログインできますね。

round8
$2y$08$qEswpql7zOBs6UleOBC.2uyw3qzsInlrVXTq/oCdFcWpOqVlRU0/C
ストレッチング8(2^8)でも問題なく入れます。

Bcryptとは

Bcryptとは?
– Blowfish暗号を基盤としたパスワードハッシュアルゴリズム
– 一般にパスワードは一方向性関数の性質を持つハッシュ関数を用い値ハッシュ値で保管する

ハッシュする際に、ソルトとストレッチングを実施する

ソルトとは
-> パスワードに付与するランダムな文字列
-> レインボーテーブル攻撃だと、ソルトが付与されているハッシュ値だと推測できない
-> ソフトはユーザ毎にランダムな値で生成することが望ましいとされている

ストレッチング
-> ハッシュ関数を用いてハッシュ値への計算を数千回〜数万回繰り返し実施
弱いパスワードや文字数が長くないパスワードは総当たり攻撃(ブルートフォース攻撃)などで時間をかければ元のデータを推測されてしまう可能性がある

“hogehogehoge”をbcryptでハッシュ化してみる
$2y$10$WjqfZuhkX4nwfkdlB0Itxu.Vr2EcIcNJlGbhkyOVfWDhtCO9zMSSa
$2yはハッシュアルゴリズムのバージョンを示す。2, 2a, 2b, 2x, 2yなどがある
$10はストレッチングの回数

ソルト(22文字)
ストレッチング回数の後の128ビット(22文字)がソルト
ソルトの後の184ビット(31文字)は結果のハッシュ値

なるほどどういう仕組みか大まかな概要は理解した。
ストレッチングの回数を変更してもアルゴリズムは変わらないはずだから、phpのbcrypt(password_hash)のストレッチングが10(2の10乗で1024回)でも12(2の12乗)でも元が同じならログインできるでOK?

[AWS S3Client] ListObjectsで1000件以上取得する書き方

Aws\S3\S3Clientで画像を取得する際に、1000件を超えると、1000件までしか取得できない。

-> ListAllObjectsを使おうとするとエラーになる。
-> $s3client->getPaginatorを使用する。

$s3client = new Aws\S3\S3Client([
    'credentials' => [
        'key' => $key,
        'secret' => $secret,
    ],
    'region' => 'ap-northeast-1',
    'version' => 'latest',
]);

$results = $s3client->getPaginator('ListObjects',[
    'Bucket' => $bucket,
    'Prefix' => $prefix,
    'Delimiter' => "/"
]);


$list = array();

foreach ($results as $result) {
    foreach($result["Contents"] as $object) {
        if(substr($object['Key'],-1,1) != "/"){
            array_push($list, substr($object['Key'], 4));
        }
    }
}
echo count($list);

$ php app.php
1069

参考ページ: https://docs.aws.amazon.com/ja_jp/sdk-for-php/v3/developer-guide/guide_paginators.html

焦るがなー 画像ファイル側に何かあったのかと思って冷や汗かいたわ。

systemctl startを実行するshellを書いてcronで実行する

まず、hello deamonはdeactiveの状態
$ sudo systemctl status hello

### shellを書く
exe.sh

#!/bin/sh
 
LOG=`sudo systemctl start hello`

$ sudo chmod 0755 exe.sh

### shell実行
$ sh exe.sh

$ sudo systemctl status hello
● hello.service – hello daemon
Loaded: loaded (/etc/systemd/system/hello.service; enabled; vendor preset: disabled)
Active: active (running) since 水 2021-01-20 10:58:55 JST; 21s ago
Main PID: 7450 (hello.sh)
CGroup: /system.slice/hello.service
├─7450 /bin/bash /home/vagrant/dev/test3/hello.sh
└─7472 sleep 1

1月 20 10:58:55 localhost systemd[1]: Started hello daemon.
1月 20 10:58:55 localhost systemd[1]: Starting hello daemon…

### crontabでshellを実行
$ sudo vi /etc/crontab

* * * * * /bin/sh /home/vagrant/dev/test3/exe.sh

$ sudo systemctl status hello
● hello.service – hello daemon
Loaded: loaded (/etc/systemd/system/hello.service; enabled; vendor preset: disabled)
Active: active (running) since 水 2021-01-20 11:10:01 JST; 27s ago
Main PID: 7625 (hello.sh)
CGroup: /system.slice/hello.service
├─7625 /bin/bash /home/vagrant/dev/test3/hello.sh
└─7654 sleep 1

お、シェルで”sudo systemctl start”の実行までできました。
あとは、シェルをmysqldのプロセスが止まっていたらsudo systemctl restart mysqld.serviceにして、ec2にデプロイするだけですね。なるほど、シェルってなかなかとっつきにくいと思ってたけど、意外と便利やな。

systemctlとshellの理解を深める

### 最終ゴール
$ sudo systemctl restart mysqld.service
↑これをshellで実行したい

1.まずシェルを作ります。
hello.sh

#!/bin/bash
while true
do
	echo hello world >> /home/vagrant/dev/test3/hello.log
	sleep 1
done

2.実行権限
$ sudo chmod 0755 hello.sh

3./etc/systemd/systemの下にUnit定義ファイルを作成する
$ sudo vi /etc/systemd/system/hello.service

[Unit]
Description = hello daemon

[Service]
ExecStart = /home/vagrant/dev/test3/hello.sh
Restart = always
Type = simple

[Install]
WantedBy = multi-user.target

L ServiceのExecStartが実行したいコマンド
L Restart=alwaysはサーバが不意に落ちた時に対応

4. Unitがserviceとして認識されたか確認
$ sudo systemctl list-unit-files –type=service | grep hello
hello.service disabled

5. 起動してステータス確認
$ sudo systemctl enable hello
$ sudo systemctl start hello
$ sudo systemctl status hello
● hello.service – hello daemon
Loaded: loaded (/etc/systemd/system/hello.service; enabled; vendor preset: disabled)
Active: active (running) since 水 2021-01-20 10:35:02 JST; 14s ago
Main PID: 7220 (hello.sh)
CGroup: /system.slice/hello.service
├─7220 /bin/bash /home/vagrant/dev/test3/hello.sh
└─7235 sleep 1

1月 20 10:35:02 localhost systemd[1]: Started hello daemon.
1月 20 10:35:02 localhost systemd[1]: Starting hello daemon…

$ tail hello.log
hello world
hello world
hello world
hello world
hello world
hello world
hello world
hello world
hello world
hello world
$ sudo systemctl stop hello

$ sudo systemctl status hello
● hello.service – hello daemon
Loaded: loaded (/etc/systemd/system/hello.service; enabled; vendor preset: disabled)
Active: inactive (dead) since 水 2021-01-20 10:38:06 JST; 21s ago
Process: 7220 ExecStart=/home/vagrant/dev/test3/hello.sh (code=killed, signal=TERM)
Main PID: 7220 (code=killed, signal=TERM)

1月 20 10:35:02 localhost systemd[1]: Started hello daemon.
1月 20 10:35:02 localhost systemd[1]: Starting hello daemon…
1月 20 10:38:06 localhost systemd[1]: Stopping hello daemon…
1月 20 10:38:06 localhost systemd[1]: Stopped hello daemon.

systemctl コマンドは、”systemd” をコントロールするコマンド
なるほど、systemctl restart mysqld.serviceは、mysqldのdaemonを管理してるってことね。
やっと理解した。

アラートメッセージの色(フォントカラー)を考える

アラートメッセージのフォントカラーを考える
Bootstrapを見てみる

#dc3545

#e83e8c

うーむ、まあこれでいいんだけど。。。

### Adobeカラーホイール
adobeカラーホイールで、メインカラーの関連色(類似色、モノクロマティック、トライアド、補色、二色分割、二重分割補色)などから合いそうな色を探す。

カラーホイール使うと、プロっぽくなりますね(苦笑)

[AWS RDS] バックアップサイクルと保持期間

データベース(Amazon RDS)のバックアップ設定
– バックアップサイクル 1回/日
– バックアップ保持期間 7日

このほか、RDSでは自動バックアップ(自動スナップショット)に加えて、5分毎にデータベース変更ログのアーカイブが自動で行われる

なるほど、バックアップからの復旧もカバーしとかないとあかんのか。
障害対応は神経使うな。