利用者のバックアップの現在との差分(No.45)

to your Kindle

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
バックアップを表示
利用者へ行く。

利用者（ユーザー）についての情報。権限情報（鍵側）の集まりでしかない。
ユースケースクラスでの権限判定に使われるくらい。
実体は利用者を表すページ。それをラッピングしたのが利用者クラス。このページを作れば利用者登録になるし、SisterWikiなどで参照可能になったユーザーはログイン可能。→ X/User[?]
と、利用者の役に立つような機能のためのデータ集。
と、ページの作成者としての役目。
と、代表見解と投票に関わるもの。
→ :i/利用者クラスの高い依存性[?]
利用者（ユーザー）についての情報。データ。
ページの編集などを許可・制限するときに参照するデータの集合。
利用者と権限を結び付ける際、引数の形式を考えるのが面倒なので、利用者をVisitorとしてページに渡す（コントロールクラスが）。で、ページから利用者を参照、利用者をたらい回し。
と、利用者の役に立つような機能のためのデータ集。
みんな最初はゲスト（お客様）。ゲストが認証（ログイン）を経て特定の利用者インスタンスと結び付く。

アカウント †

利用者ごとのアカウントを。
特定のページに記述することが利用者登録になるように。
さらにグループ名を表すページを使って、そのグループに属する利用者を登録できるように。

アカウント
1. 定義の書き方
ログイン／認証
1. :i/ビルトインユーザー
グループ／ロール
権限（鍵）
1. 利用者の属性
利用者情報を必要とする機能

定義の書き方 †

文字列（利用者の属性名とその値に適合するRegExp）→アクセス権定義

ログイン／認証 †

アクセス権定義は定義の対象になるページ（ページ/属性）に書く？

:i/ビルトインユーザー †

グループ／ロール †

:/アカウントにロールは要らない †

利用者を上位ページでまとめればロールにあたる仕組みが不要。

:i/利用者をグループでまとめる[?] †

ページ/属性/継承を使ってグループ内メンバー全員の権限を設定。

:i/利用者のロールといえば †

（デフォルトで用意する）グループの候補に。
そのページのアクセス権を管理者だけ編集可能にすれば、管理者がアクセス権定義をすることになる。

:i/ロールと権限の違い †

（デフォルトで用意する）グループの候補に。
もしアクセス権定義ページを分けてサブディレクトリごとに用意できるようにするなら、ページがあるディレクトリとサブディレクトリについてのみ定義できるように。

有効期間 †

有効であり続ける条件

最終使用時刻（最後にアカウント情報が参照された時刻）からの時間が有効期限内
アカウント情報を使わないような操作が続くと無効になる？→別にいい？
同一端末を使っている
同じIPアドレス。同じUAかどうかは不要。
はてなでもやっている？
これがあると不便？PCで編集しながら携帯での見え方をチェックすることができない。

:i/下位ロールを作れるロール[?] †

Wikiを構築するために。運用でロール作成。

権限（鍵） †

無効になる条件

ユーザーからのリクエスト
「ログアウト」した時。
有効期限を過ぎた
アカウントが削除された

利用者の属性 †

利用者に関する情報で文字列で表せるもの全て。
Googleさんだけ個別化して、特定のページを見せるなら属性「User-Agent」に/googlebot/があることを調べる。

利用者情報を必要とする機能 †

要するにカスタマイズ。

非公開編集 †

アカウントを持っている人がゲストとして書き込むのもいい。
編集履歴に自分のアカウントが記録されないので、「隠れた編集」や「非公開編集」とも言える。

:i/検索履歴 †

:Done/ユーザーページではなくワークスペース †

利用者が自分用に使うページ群（下位ページ含めて）ということ
これを作ることが参加／ユーザー登録になるということ

†

利用者と権限を結び付ける際、引数の形式を考えるのが面倒なので、利用者をVisitorとしてページに渡す（コントロールクラスが）。
で、ページから利用者を参照、利用者をたらい回し。
…を明確に表現する呼び方は？

「（利用者名）のワークスペース」
~~「（利用者名）のためのWiki」~~
~~「（利用者名）の作業用Wiki」~~
~~「（利用者名）の居場所」~~
~~「（利用者名）」~~

未分類 †

リクエスト、ログ読み（未読） †

人気ページは「充実させてほしい」というリクエストの表れ。
編集者が自分が編集するペースで（というか、前回アクセスから今までの期間で）人気のあるページを調べられれば、
「次に編集すべきページ」「期待されているページ」というものが分かる。

:i/ユーザーを個別化するには †

アクティビティの収集など。個別化は自動的なカスタマイズにもなる。利便性向上に。
掲示板での「ログ読み」「未読」をWikiでやるならば、前回アクセス以降の差分（全ページ分）閲覧と、前回アクセス以降の人気ページを知ることになるのでは。

:i/管理アカウントは一般アカウント †

多重ログイン。複数セッション。
Atlassian Confluenceはこうなっている。

:i/メンテナンス要員 †

詳しい人を招いたときのロール。

利用者/ †

:i/管理者は誰かという定義をページで †

最初の管理者はどう決めるか。管理者というより所有者（オーナー）を定義。

tag:利用者 †

利用者

:i/情報はページに †

ページはデータベース。利用者もページ/要素と同じ方法で情報を記録。ページ/要素は要素間連携と同じ方法で利用者情報を参照できることになる。

:i/ページのauthor属性 †

セマンティックなWikiのために。TwitterCardsをURIあたり1つしか付けられないのなら、最優秀功労者を決めないと。その方法は？
→共著も表現できるはず。

:i/投稿時の自動署名はない †

投稿時のコメント欄（MediaWikiのような）があれば自動署名もあり。

:i/ページ/属性/作成者 †

利用者IDはページに記録される。どのページのどの版にも1つ。

:i/追加のみと書き換えの権限を分ける †

権限は雑多。重複がある。個別に考えなければならないし、判定は個別のコードで行なわないと。

:i/著作権に基づいた権限設定 †

権限のコンセプト。権限とはドキュメントに関する権利を守るためのもの。

:i/自分のサイトへトラックバック送信 †

利用者情報に「トラックバック先」。他にもTwitter アカウントとかあってもいいかも。
Twitterとの連携でリプライの連鎖をwikiに取り込むTogetterクローンみたいな機能を使えるなら、発言はTwitter側でもwiki側でもいいことになる。

:i/利用者ページの見られ方 †

見られ方=見解。利用者の見られ方（側面、インターフェイス）といえばロール。利用者は複数のロールに属せるし、ロールは周囲から期待される役目のこと。利用者ページの見られ方=見解として良さそう。
でも見解は他の見解を隠すためのもの。~~汎用性がない。~~→「他を隠す」というより「代表的なものがある」と考えると問題ない。
側面は見る側が選ぶというのは星。
多くの人か選んだ見解がゲスト向けのデフォルト見解になるというのも星。
見解ごとにそのロールで役立つような機能やフォーム（管理者なら連絡用フォームとか）を用意しておけば有意義。

:i/利用者名はニックネーム †

利用者情報に「利用者名」または「ニックネーム」を設けて。Twitterでのdisplay_nameになるのはニックネーム？ID？IDは認証に使ったサイト名を含んでいる。
†:i/OAuth+ID+表示名
→重複していいので利用者自身が自由に設定。一部でもシステムが決めるのなら非公開に。本人が決めたものではないので。

:i/利用者ページに書くこと †

設計のコンセプト。利用者ページのページ/裏のほうはシステムが書き込むものなので設定項目用かも。

:i/ロール別のビュー †

利用者を分けたときの一番の効果。モード変更なので、他のロールと切り替えて（例えば閲覧者と編集者）使用できないと。切り替えするのは利用者自身。
実装方法は…
†:i/二重ログイン可能[?]
†:i/パスワードを複数設定
ログイン／ログアウトだけ？切り替えUIは不要？
→ログイン後のログインで。途中のログアウトは不要。

:i/利用者を何と結び付けるか †

認証方法の考え方。既存の所有権と関連付けることが認証。

:i/利用者をグループでまとめる[?] †

†:i/ロールと権限の違い
†:i/利用者のロールといえば
†:/ロールをページ化、利用者を下位ページ化
まとめて管理。まとめて権限設定。設定時に権限を要するがまとめておけば利用者ページごとの権限判定にはならない。判定対象はグループページと管理者の間だけ。
†:Done/属性継承時の権限判定は？

利用者でやること