経緯
- 所属大学の学科にて研究室配属世話人になった
- 昨年度のシステムについて保守担当が今年からいないため対応が不安
- 3年連続くらいで大学と齟齬が発生している
-> 今年の代で新規に作成する必要がある
条件
- 成績データに関して過去年度で問題が発生しているので透明な仕組みが必要
- 対象ユーザ(学生)は100名ほど
- 繊細事項であるため，不正防止措置は必須
- 開発期間は1ヶ月程度
- レポート期間等の大忙し時期と丸被りしている
- jsの開発経験がない
部外秘事項が多数であるため，技術的詳細についてのみ記載する
構成について
当初は以下の構成を目指していた．
- 成績データ：大学ポータルサイトよりスクレイピング
- フロントエンド：JavaScript
- バックエンド：GAS
- DB：Google スプレッドシート
しかし，GASの同時接続可能数が30名程度であると判明し，取りやめになる
最終的に以下の構成となった．
- 成績データ：大学ポータルサイトよりスクレイピング
- フロントエンド：JavaScript，HTML
- バックエンド：Firebase
- DB：Cloud Firestore
- 環境：Node.js
クライアントの規模と開発コストより，クライアント直結型のシステムとした．
認証及びアクセス権限管理は，GCP(Google Cloud Platform)及びFirebaseによって行う．
成績データの取得について
成績データは諸事情より大学ポータルサイト内の成績情報ページより直接取得することにした．
ここで学生認証がネックとなったため，ログインをユーザにさせて認証完了後からスクレイピングを行うこととし，そのためにブラウザ拡張機能として実装した．
不正対策について
システムの目的上，不正行為は最大限対策する必要があった．
想定される不正行為として以下のものがあった．
- DOM書換えによる成績の改ざん
- クライアントシステムの改変による成績の改ざん
DOM書換え対策について
DOM書換え対策としてスクレイピング直前に画面リロードを実装した．
ただ，拡張機能単位での画面リロード後の画面要素取得には一定の順番が存在するため，画面リロード後に当システムが要素取得するより早期に他の拡張機能によって画面が書き換えられる恐れがあった．そのため，研究室エントリー操作時にも同様の手順で成績情報を取得し，登録している成績との整合性を確認するようにした．
また，難読化パッケージのオプションにて，DOM書換え防止を指定することでも対策とした．
クライアントシステムの改変対策について
クライアントシステムの改変対策として，ソースコードのバージョン管理とソースコードの難読化を行った．
-
ソースコードのバージョン管理
成績登録の際に，ソースコード全体をハッシュ化して同時に送信するようにした． -
ソースコードの難読化
webpack-obfuscatorによってソースコードを難読化した．
加えてself-defendingオプションを指定した．
参考