POST /patient/login に、RefreshToken 値を追加する

SMSでログインURLを送った際、IdToken で認証をする仕組みは作れるが、それだと RefreshToken を返すことができない。
RefreshToken を返すためには、 Cognito の AdminInitiateAuth を実行して RefreshToken を取得、返却する必要がある。

/patient/initialize/ メソッドを作り、以下の処理を行う

• Patient で認証
• 渡された IdToken からユーザIDを取得
• 新規にパスワードを生成/設定する（cognito.adminSetUserPasswordを実施）
• 新規にセットしたユーザID/パスワードで、signIn を実施
• 戻ってきた refreshToken, idToken を返却する

最新のユースケースシナリオはこちら
https://miro.com/app/board/o9J_laUr9s8=/
閲覧パスワードは remote-monitoring です。何か補足や懸念等あればコメントを入れて下さい。

元になった、takahashimさん作成のユースケース

現在 centerId のみを返しているので、centerName と emergencyPhone も加える

Sprashスクリーン表示やアイコンに使う

• データを自動で取得し、Android 端末などに送信できる
• Android 端末側のアプリから、そのデータを取得できる
• 時間があまりかからずに入手可能
  という要件が必要

AWS Console の ID token expiration 設定を AWS Console から変えれば良いが、Serverless の設定にしておきたい。

npm install 実施で eslint のバージョンが上がったから？

内容

• ESLint, Prettierを導入することでTypeScriptのコーディング規約に沿ってかけるので何処かのタイミング(リファクタリングなど)で入れても良いかもしれません。

必要な作業

• ESLint ,Prettierのインストール
• Lintの設定
• Lintエラーになる部分の対応
  • リファクタリングの規模と要相談

Patient ユーザを登録した際に、入力されたスマートフォンの番号に向けて、下記の文面のSMSを送信する

毎日の体調を入力いただく、遠隔療養者モニタリングシステムのログイン用URLです。
https://monitoring.stopcovid19.jp/login?idToken=${idToken}
このURLはあなた専用の入力画面です。他の人には転送しないようにしてください。

後にSMS送信用のAPIを使えるようにする予定だが、当面は AWS での送信で構わない

https://github.com/codeforjapan/remote-patient-monitoring-api/blob/8086899a00a8c8b343581331f909b465ac542083/docs/DEVELOPMENT.md#4-setup の手順にそって npm run deploy && npm run deploy:gateway を実行時に以下warning表示後にデプロイが失敗しました

Serverless Warning --------------------------------------

  A valid file to satisfy the declaration 'file(./templates/functions-aws.yml)' could not be found.

templates配下には functions-.yml と functions-true.yml は存在するが、 functions-aws.yml は存在しないためこのエラーになっていると思います。

デプロイプロセス全体の関連を把握できていないのですが、セットアップ時に /templates/functions-aws.yml の追加が必要でしょうか? あるいはデプロイ手順、serverless.ymlに何らか変更を加えるべきでしょうか?

center モデルに、emergency_phone を追加

テストの際にいちいちユーザ作ってからテストするのが大変。
fulltest 時にテストユーザを作ってしまうようにする。
そのためには、実行前に cognito のユーザープールも初期化する必要がある

患者がモバイルアプリ/webから入力する項目を確定する必要があります。

2020/12/27

• 咳
• 痰
• 息苦しさ
• 頭痛
• 喉の痛み
• その他・連絡事項：「　　　　　　　　　　　」

に決定。
ワイヤーフレームに反映した。

sls deploy --stage stg で、staging 環境を起動できるようにしたい

現在、patientIdを付与しないとpostできない。

symptoms

• couth -> cough
• phiegm -> phlegm

#15 より。

curl -X GET "https://monitoring.stopcovid19.jp/stg/api/nurse/nurses/testNurse" -H "accept: application/json" -H "Authorization: ..."

{
  "manageCenters": [
    {
      "centerId": "79167710-2761-4cf4-8888-241e9f0c36b8"
    },
    {
      "centerId": "a8d3203d-9ca9-494b-9581-7e965cc96bbf"
    }
  ],
  "nurseId": "testNurse"
}

IdToken 以外に RefreshToken も返却する

存在しない center に対する post

CONTRIBUTING.md内のCONTRIBUTORS.mdへのリンクが切れています。

memo は一旦サーバ側で持つ

ユーザ登録時にログインURLをSMSで送信して、そこからでも入れるようにしたい。
IdToken をURLに付けた形でもログインができるようにする

`/patient/login/${base64 エンコード

患者（モバイル）側、保健師側の両方で認証が必要そうです。

患者側

• ふつうにID/Password方式でよいのか
  • 使いこなせるかどうかが割と心配…（紙に書いたIDとパスワードを渡す方式ならいける？）
• IDはメールアドレスにするか、それとも何らかのIDにするか
  • なんとなく、保健所側で発行する方が確実な気もする。おそらく現状の保健所ではメールアドレスは管理してなさそうだし。
  • ちなみに保健所からメールを飛ばせる必要はある？
• パスワードは再発行できるようにするか
  • 忘れたら電話してもらって、電話口で教えた方が早そうな気もする（特にメールアドレスを管理しない場合。まあSMSを使う方法もありますが）。基本的には2週間程度有効であればよいはずだし

保健師側

• 複数人が見る場合、厳密に（保健師ごとに）ID・パスワード管理を行うべき？
  • その場合、保健所側の作業になるのか、システム管理者？側の作業になるのか
  • 個人情報保護規程みたいなものでauditのルールが決まっていたりする？（認証とはちょっとずれますが、いつ誰がどのデータを見たかが全てtrackingできないとNGなのか、ふつうにダッシュボード的に表示してるんだからログインした人＝見てる人という前提が成り立たないので気にしなくてOKなのかが気になってます）

/patient/patients/他人のID は表示できないように

#3 と連動

• 携帯電話番号を受け取る
• その電話番号がPatientDBに登録済であれば、その電話番号にSMSでログイン用URLを送信する

Issueとして立てました。

前回から進んだこと。

• jest を使って、e2e テストを先に書くことにした。（まだ途中）
• テスト用に、db の初期化や authentication 系のコードを追加した
• sls offline で、lambda をローカル実行できるようにした(DEVELOPMENT.md を参照のこと)

e2e テストシナリオ

実装しようとしているテストシナリオは下記。ユニットテストはとりあえず後回し。--runInBand で逐次実行する。
テストケースが一通り書ければ、作業分担がしやすくなる。
リファクタリングもやりやすい。

• truncate tables
• anonymous で API を叩く。 /get/centers 等の一部のコマンド以外はエラーになることを確認
• admin user でログインできることを確認
• admin user の IdToken を Authorization ヘッダにセットして、下記を実行
  • center への get/post/put 操作
  • patient への get/post/put 操作
  • nurse の登録操作（Cognito でユーザを作る）
  • status の get/put 操作
• 前段階のテストで作成した nurse アカウントでログインできることを確認
• nurse user の IdToken を Authorization ヘッダにセットして、下記を実行
  • admin 系の操作ができないこと
  • patient の get/post/put 操作
  • status の get/put 操作
• 前段階のテストで作成した patient アカウントでログインできることを確認
• patient user の IdToken を Authorization ヘッダにセットして、下記を実行
  • admin/nurse 系の操作ができないこと
  • status の get/post/delete 操作
• truncate tables

残作業(プライオリティ高い順)

• テストシナリオの残りを書く（とりあえず期待する動作のみで中身は書かない）
• ユーザ登録まわりの処理を書く(そうしないと nurse とかのコードが書けない)
• 残りの処理を書く(現在は /admin/ の一部しか無い)
• リファクタリング
• ユニットテストを書く

何かおかしいところ

デプロイ後、lambda が実行できなくなるときがある。こちらの手順 で直る。

誰かに見て欲しいところ

serverless.yml の書き方が美しくない気がする。
特に、API Gateway の CLIENT_POOL を設定するために2回デプロイしているところ。更に、手動で deploy api しないとその情報が反映されないので不便。 #50 で解決。

新しい順に並べたい

DELETE /stg/api/patient/patients/testPatient/statuses/undefined

などと送ってもステータスコード200 が帰ってくる。エラーが出るべき

できるだけ運用しやすいことを重視。
AWSが望ましい

最新のユースケースシナリオはこちら
https://miro.com/app/board/o9J_laUr9s8=/
閲覧パスワードは remote-monitoring

ワイヤーフレームはこちら
https://www.figma.com/file/29X7k8bKfFlWS6Md5BhrME/UI-Template-Copy?node-id=41%3A0

patient のログイン時に policy_accepted の値を返す
#94 に関連

大阪の例

http://www.pref.osaka.lg.jp/iryo/2019ncov/sisutemuriyoukiyaku.html

PUT /api/nurse/patients/{patientId}

に、display 項目も必要

一度付与したmemoを「空欄にする」ことができない

いちいちメールでテンポラリーパスワードを取得する必要が無いはず

/patient/patients/${patientId}/accept_policy に POST method を送るとポリシーをアクセプトする。

対象API

• /api/admin/patients/{patientId}/statuses POST
• /api/nurse/patients/{patientId}/statuses POST
• /api/patient/patients/{patientId}/statuses POST

Lambda名

• remote-Status-monitoring-postStatus-{Stage名}
• remote-patient-monitoring-postStatus-${Stage名}
  • 他のLambdaの命名規則に合わせました。

作業項目

• 作業前の質問・確認事項洗い出し
• API実装
• 動作確認 (E2E)

PR

DEVELOPMENT.md に書きましたが、deploy 時にAPIがうまく動作しないケースがあります。

• lambda function の KMS まわりがエラーになる
• API Gateway から lambda を実行する権限がなくなる (解決済み)

という2つのエラーがありますが、原因が不明です。AWS に詳しい方、どなたか調査いただけると助かります🙏。

クライアント側でも対応するが、サーバ側でもハイフンの削除を行っておく

モバイルアプリとウェブアプリの両方でワイヤーフレームが必要
Figma 等の、デザインを共有できるツールでの作成が望ましい

ネイティブアプリの場合、COVID-19関連のものは審査が通りにくい。そもそも一般企業はアプリを出せないことが多い。
一般的な健康観察アプリとしてならいけるかもしれないが、時間がかかることが想定される。

パルスオキシメーターからのデータの自動入力アプリは一旦後回しにして、PWA アプリとして展開するのが良さそうに思う

#3 と連動

スマホから入力されたデータを表示するダッシュボード