博多南ウェブサービスのblog

博多南ウェブサービスのサービス紹介

【Play Framework 2.8.x と PayPay for Developers サンプル】Polling of Get Payment/Refund Details のために、Play ws を使う

Play Framework を始めたばかりの方向けに、サンプルを進めるうえで困ったところを共有する目的で書いています。

Play Framework 2.8.x と Play WSを使って、Polling を実装したときのメモです。

以下、目次

できたこと

  • 非同期の Polling
  • TLS v1.3 での アクセス (環境は、AdoptOpenJDK jdk-11.0.11+9 HostSpot)

やっててつまづいたこと

  • WS について、default の設定だと TLS v1.2 でアクセスするが、1.3 に変更する設定がすぐには見つからなかった(play.ws.ssl.protocol = "TLSv1.3" でうまくいった)

参考にしたところ

Githubこちら

以上でした。

【Play Framework 2.8.x と PayPay for Developers サンプル】ウェブペイメント-即時売上における Webhook 通知を受け取りたい

Play Framework を始めたばかりの方向けに、サンプルを進めるうえで困ったところを共有する目的で書いています。

Play Framework 2.8.x を使って、ウェブペイメント-即時売上における Webhook 通知 受信を実装したときのメモです。

以下、目次

できたこと

やったことの流れ

  1. IP フィルタリング機能の実装 (Play にあるだろうと思っていたらなかった)
  2. heroku へのアップ
  3. PayPay for developers ログイン -> 構成 にて「突合ファイル通知Webhook」「決済トランザクション通知Webhook」を設定
  4. 受信の検証

やっててつまづいたこと

  • heroku 環境にて、リクエストの IP を取得する際、Request#remoteAddress だとヘッダー 'X_FORWARDED_FOR' の値を取得しない(なんでだろう?)
  • 突合ファイル通知Webhook は夜中4時あたりにのみ送信されるはずが、されない(PayPay 側での設定漏れがあった模様。問い合わせにて判明・解決)

参考にしたところ

Githubこちら

以上でした。

メモ:日立衣類乾燥機 DE-N50WV の修理(日立衣類乾燥機ケーシング/ネツコウファンクミDE-N4S 010 の交換)

自宅で使っている衣類乾燥機を修理した時のメモ。

なお、家電製品の修理については、 細心の注意をもって自己責任の範囲で行うべきだと考えます。 また、電気が通っている部分、回転する部分、大きな力がかかる部分などは、 事故・けがの可能性を考慮して、販売店や修理専門業者に依頼するほうが良いと考えます。 この記事を参考に、ご自分で修理される方に生じた何らかの損失、損害等について、 私は一切責任も負うものではありません。

状況

  • 動かしているときの音が大きくなった
  • 普段の動作音とは異なる音(キュルキュル)が鳴り出した
  • 回転が始まらず、エラー音とともに動作が止まった

故障個所

  • ベルトが切れてる、部品が割れている等見てわかる破損はなし
  • ファン?(背面の大きな羽)の軸部分をよくみるとひび割れが見える(がもともとあったのかの判別はできない)

修理に必要だったもの

  • ドライバー
  • モンキーレンチ
  • ラジオペンチ
  • 日立衣類乾燥機ケーシング/ネツコウファンクミDE-N4S 010
  • 日立 HITACHI 衣類乾燥機用マルベルト(ファン用) DE-N45R7-016
  • 日立 HITACHI 衣類乾燥機用Vベルト DE-N50K3-046
  • 軍手

今後修理するときのメモ

  • ねじ止めしている箇所を、外す前に画像にとっておく(どこをとめるかわからなくなる)
  • ワッシャーとボルトの位置関係を、外す前に画像にとっておく(やっぱりわからなくなる)
  • マジックで直接メモ書きしてもよい(どうせ中は見えないのだから)
  • 磁石付きのドライバーは楽
  • 電動ドライバーが欲しくなる

参考リンク

【Play Framework 2.8.x と PayPay for Developers サンプル】ウェブペイメント-即時売上の返金/キャンセルをしたい

Play Framework を始めたばかりの方向けに、サンプルを進めるうえで困ったところを共有する目的で書いています。

Play Framework 2.8.x 、paypayopa-sdk-java 1.0.3 を使って、ウェブペイメント-即時売上の「返金」「キャンセル」を実装したときのメモです。

以下、目次

できたこと

  • 決済用のQRコード作成
  • 決済ステータスの確認
  • キャンセル/返金

できていないこと

  • Polling による決済ステータスの確認
  • webhook の利用

設計時に迷ったところ

  • キャンセルの判定に使う翌日って、日本時間?API で帰ってくるのってエポックタイムスタンプだけど(多分そう)

    通常の決済フローでは基本的には、Cancel a paymentを使いませんが以下の場合に利用ください。

    • Capture a payment authorizationがタイムアウトし、キャンセルを実施したい場合
    • Get Payment Detailsを実行したが状態がわからない場合

    注:Cancel a paymentは、支払いが行われた翌日の00:14:59まで使用できます。 00:15 AM以降の場合、Refund a paymentを呼び出して支払いを払い戻します。

  • キャンセルと返金は、自分で判定してAPI呼ばないとだめ?

実装時に迷ったところ

  • java.timeZonedDateTimeOffsetDateTimeって何?違いは?(わからない)

参考にしたところ

Githubこちら

以上でした。

【Play Framework 2.8.x と PayPay for Developers サンプル】ウェブペイメント-即時売上をしたい

Play Framework を始めたばかりの方向けに、サンプルを進めるうえで困ったところを共有する目的で書いています。

Play Framework 2.8.x 、paypayopa-sdk-java 1.0.3 を使って、ウェブペイメント-即時売上の「決済」「決済ステータス確認」を実装したときのメモです。

以下、目次

できたこと

  • 決済用のQRコード作成
  • 決済ステータスの確認

できていないこと

  • キャンセル/返金
  • Polling による決済ステータスの確認
  • webhook の利用

大まかな設計内容

  • 注文時の画面遷移:Item の選択→選択内容の確認→支払い用 QR コード→決済ステータス確認
  • クライアント→サーバーへの注文データ送信・チェックは、Play Framework の Form を利用
  • 注文内容の確認用に、注文内容の Hash Code を Cookie (Play Framework では Session) に保存

設計時に迷ったところ

  • 注文時のフローは、選択→確認→決済とした(一般的な Web での注文も確認画面がある)が、確認はなぜ必要?
  • 確認画面からデータを送るときは、Post で送る?セッションに持たせる?
  • Redirect after Post (他には、Post/Redirect/Get みたいな言い方も)とは何?
  • 生成した QR コードに2重支払いが発生するパータンはある?
  • Post したデータは、どうやって Parse する?自分で実装しないとダメ?

実装時に迷ったところ

  • getCodesPaymentDetails は使えて、getPaymentDetails は使えない?(ウェブペイメントでは使えない
  • 生成した QR コード画面を表示→戻るボタンを押したら、支払い画面にもどれない?( PaymentApi にはない。多分もどらせずに、再度生成させるのを想定している?)

参考にしたところ

Githubこちら

以上でした。

【Play Framework 2.8.x と play-pac4j サンプル】Authority の有無で、(403 Forbidden を返さずに)html の内容を変更したい

Play Framework を始めたばかりの方向けに、サンプルを進めるうえで困ったところを共有する目的で書いています。

Play Framework 2.8.x 、および play-pac4j v5.1 を使って、Authority check 結果によって、(403 Forbidden を返さずに)html の内容を制御したときのメモです。

以下、目次

前提

  • pac4j の Default Security Logic では、Authority check の結果、エラーステータス(例:403 Forbidden)をかえす
  • エラーページではなく、見せる内容の変更だけしたい(ゲストには正常のページを見せ、管理者には追加で編集メニューを見せる)

大まかな設計内容

参考にしたところ

Githubこちら

以上でした。

【Play Framework 2.8.x と play-pac4j サンプル】Authority Check のとき、Cache にあるデータとの check をしたい

Play Framework を始めたばかりの方向けに、サンプルを進めるうえで困ったところを共有する目的で書いています。

Play Framework 2.8.x 、および play-pac4j v5.1 を使って、Cache にあるデータとの Authority check を実装した時のメモです。

以下、目次

できたこと

  • Cache に認可用のデータ(本実装は typedID、および role)があるかどうかチェック処理
  • 認可用データの更新時間と、サインインした時間との比較チェック処理

pac4j の認可機能ではだめだった理由

pac4j v5.1 で用意されている Default Authorizer は、

  • Profile のもつ Role or Permission or Attribute
  • Authorizer の持つ文字列

の2つを(String の Matcher で)比較チェックするタイプ。

また、pac4j の認可機能は、
Authorizer (認可判定部分)を Config に登録
-> Default Security Logic で、Config 登録された Authorizer を検索し呼び出す
といった流れになる。

本実装では、Authority に有効期間を設定し、期限切れであれば拒否したかった(かつ、有効期間は一定ではない)ので、 RequireAnyRoleAuthorizer 等は使えなかった。

大まかな設計内容

pac4j の認可機能の流れはそのままで、チェック部分だけ変更したかった(Security Logic には触りたくない)ので、 大きく、以下の2つを実装した。

  • 認可用のデータを(本実装ではキャッシュから)取得する部分 (repository)
  • 認可判定時に、データを都度取得するよう呼び出す部分 (authorizer)

認可用のデータを(本実装ではキャッシュから)取得する部分 (repository)

認可用データを取得する部分を、関数自体を定義・渡す ことで、都度取得させている

trait AuthorityRepository {
  def getTypedIdRoleAndUpdateAtMap: ResourceId => TypedIdRoleAndUpdateAtMap
}

認可判定時に、データを都度取得するよう呼び出す部分 (authorizer)

class RequireAnyNewerRole引数を遅延評価する ことで、 Config に登録しても認可判定時に都度データ取得させている。

class RequireAnyNewerRole(
    allowedTypeIdRoleAndUpdateMap: => TypedIdRoleAndUpdateAtMap
) extends ProfileAuthorizer

なお、認可用データの更新時間と、サインインした時間との比較チェック処理は、 Role でやっている。

参考にしたところ

Githubこちら

以上でした。