目次 Edit

  1. 目次
  2. 関連
  3. 利用者周辺のタグ
  4. 利用者
    1. ログイン/認証
    2. 利用者/ロール
  5. 思い付き
    1. :i/ビルトインユーザー
    1. グループ/ロール
      1. :/アカウントにロールは要らない
      2. :i/利用者をグループでまとめる[?]
      3. :i/利用者のロールといえば
    2. 利用者名にはIDから得たハッシュ値を付ける
    3. 自動署名はない
    4. 権限設定で、追加のみと既存部分を書き換えられるのを分ける。
      1. :i/ロールと権限の違い
      2. :i/下位ロールを作れるロール[?]
    5. 権限(鍵)
    6. 「あなたと似ている利用者は…」を「あなたにふさわしい派閥は…」に
    7. 利用者情報を必要とする機能
  6. 実装
    1. 情報はページに
    2. 管理者定義
      1. :i/検索履歴
      2. :Done/ユーザーページではなくワークスペース
    3. 高い依存性
    4. 未分類
      1. :i/ユーザーを個別化するには
    5. アカウント
      1. :i/管理アカウントは一般アカウント
      2. :i/メンテナンス要員
      3. :i/管理者は誰かという定義をページで
      4. :i/情報はページに
      5. :i/ページのauthor属性
      6. 利用者の属性
      7. :i/投稿時の自動署名はない
      8. :i/ページ/属性/作成者
      9. :i/追加のみと書き換えの権限を分ける
      10. 非公開編集
      11. :i/著作権に基づいた権限設定
      12. :i/自分のサイトへトラックバック送信
      13. :i/利用者ページの見られ方
  7. 設計
    1. :i/利用者名はニックネーム
    2. :i/利用者ページに書くこと
    3. :i/ロール別のビュー
    4. :i/利用者を何と結び付けるか
    5. :i/利用者をグループでまとめる[?]
    6. :i/オープン認証ではユーザーIDにサイトドメイン追加
    7. :i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク
    8. :i/アンケートは自分のページに回答を書く
    9. :i/アカウント削除予約
    10. :i/おかえりなさいメール
    11. :i/Wiki構築には2つの側面がある
    1. 利用者/
 
 

利用者ユーザー)についての情報。権限情報(鍵側)の集まりでしかない。

ユースケースクラスでの権限判定に使われるくらい。

実体は利用者を表すページ。それをラッピングしたのが利用者クラス。このページを作れば利用者登録になるし、SisterWikiなどで参照可能になったユーザーログイン可能。→ X/User[?]

関連 Edit

 
 

検索:利用者
 

と、利用者の役に立つような機能のためのデータ集。

と、ページの作成者としての役目。

と、代表見解投票に関わるもの。

→ :i/利用者クラスの高い依存性[?]

利用者周辺のタグ Edit

Array
 

利用者権限を結び付ける際、引数の形式を考えるのが面倒なので、利用者Visitorとしてページに渡す(コントロールクラスが)。で、ページから利用者を参照、利用者をたらい回し。

みんな最初はゲストお客様)。ゲスト認証ログイン)を経て特定の利用者インスタンスと結び付く。

利用者 Edit

  1. 目次
  2. 関連
  3. 利用者周辺のタグ
  4. 利用者
    1. ログイン/認証
    2. 利用者/ロール
  5. 思い付き
    1. :i/ビルトインユーザー
    1. グループ/ロール
      1. :/アカウントにロールは要らない
      2. :i/利用者をグループでまとめる[?]
      3. :i/利用者のロールといえば
    2. 利用者名にはIDから得たハッシュ値を付ける
    3. 自動署名はない
    4. 権限設定で、追加のみと既存部分を書き換えられるのを分ける。
      1. :i/ロールと権限の違い
      2. :i/下位ロールを作れるロール[?]
    5. 権限(鍵)
    6. 「あなたと似ている利用者は…」を「あなたにふさわしい派閥は…」に
    7. 利用者情報を必要とする機能
  6. 実装
    1. 情報はページに
    2. 管理者定義
      1. :i/検索履歴
      2. :Done/ユーザーページではなくワークスペース
    3. 高い依存性
    4. 未分類
      1. :i/ユーザーを個別化するには
    5. アカウント
      1. :i/管理アカウントは一般アカウント
      2. :i/メンテナンス要員
      3. :i/管理者は誰かという定義をページで
      4. :i/情報はページに
      5. :i/ページのauthor属性
      6. 利用者の属性
      7. :i/投稿時の自動署名はない
      8. :i/ページ/属性/作成者
      9. :i/追加のみと書き換えの権限を分ける
      10. 非公開編集
      11. :i/著作権に基づいた権限設定
      12. :i/自分のサイトへトラックバック送信
      13. :i/利用者ページの見られ方
  7. 設計
    1. :i/利用者名はニックネーム
    2. :i/利用者ページに書くこと
    3. :i/ロール別のビュー
    4. :i/利用者を何と結び付けるか
    5. :i/利用者をグループでまとめる[?]
    6. :i/オープン認証ではユーザーIDにサイトドメイン追加
    7. :i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク
    8. :i/アンケートは自分のページに回答を書く
    9. :i/アカウント削除予約
    10. :i/おかえりなさいメール
    11. :i/Wiki構築には2つの側面がある
    1. 利用者/

ログイン認証 Edit

利用者/ロール Edit

  • 読む人
    ブックマークしてるリピーターの人、検索サイトから来た飛び入り参加の人など。書く人の相手。
  • 書く人
    コンテンツに詳しい人。サイトの原動力。
  • 構築する人
    WikiEngineに詳しい人。プラグインを利用して、Wikiをより活用しやすくする人。Wikiを改造する人。
  • 管理する人
    サイトの管理者。責任者。お金を出す人。何かあると怒られる人。管理者設定をする人。

思い付き Edit

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

グループロール Edit

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


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

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


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

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


(デフォルトで用意する)グループの候補に。

利用者名にはIDから得たハッシュ値を付ける Edit


IDを公開してもいいならIDをそのまま付けてもいい。

で…
  • 同じニックネームがあってもいいように
  • いつでもニックネームを変えられるように

自動署名はない Edit


名前は自分で書くこと。

権限設定で、追加のみと既存部分を書き換えられるのを分ける。 Edit


これらは包含関係。(編集>追加のみ)

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


(デフォルトで用意する)グループの候補に。

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


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

権限(鍵) Edit

「あなたと似ている利用者は…」を「あなたにふさわしい派閥は…」に Edit

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


要するにカスタマイズ。

実装 Edit

情報はページ Edit


利用者はオブジェクト。でも関連する情報はページに記録。

自分のページにある情報がそのアカウントの情報。

管理者定義 Edit


キーワード:OpenID

:i/検索履歴 Edit

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

  1. 利用者が自分用に使うページ群(下位ページ含めて)ということ
  2. これを作ることが参加/ユーザー登録になるということ

…を明確に表現する呼び方は?

高い依存性 Edit


ページや派閥と関係が深い。

利用者についてはこれらを考えてから。

未分類 Edit

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


アクティビティの収集など。個別化は自動的なカスタマイズにもなる。利便性向上に。

アカウント Edit


利用者ごとのアカウントを。

特定のページに記述することが利用者登録になるように。

さらにグループ名を表すページを使って、そのグループに属する利用者を登録できるように。

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


多重ログイン。複数セッション

Atlassian Confluenceはこうなっている。

定義の書き方
文字列(利用者属性名とそれに適合するRegExp)→アクセス権定義

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


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

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

そのページのアクセス権を管理者だけ編集可能にすれば、管理者がアクセス権定義をすることになる。

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


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

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

:i/情報はページに Edit


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

:i/ページのauthor属性 Edit


セマンティックなWikiのために。TwitterCardsをURIあたり1つしか付けられないのなら、最優秀功労者を決めないと。その方法は?

利用者属性 Edit


利用者に関する情報で文字列で表せるもの全て。

Googleさんだけ個別化して、特定のページを見せるなら属性「User-Agent」に/googlebot/があることを調べる。

→共著も表現できるはず。

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


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

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


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

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


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

非公開編集 Edit


アカウントを持っている人がゲストとして書き込むのもいい。

編集履歴に自分のアカウントが記録されないので、「隠れた編集」や「非公開編集」とも言える。

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


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

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


利用者情報に「トラックバック先」。他にもTwitterアカウントとかあってもいいかも。

Twitterとの連携でリプライの連鎖をwikiに取り込むTogetterクローンみたいな機能を使えるなら、発言はTwitter側でもwiki側でもいいことになる。

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


見られ方=見解利用者の見られ方(側面、インターフェイス)といえばロール利用者は複数のロールに属せるし、ロールは周囲から期待される役目のこと。利用者ページの見られ方=見解として良さそう。

でも見解は他の見解を隠すためのもの。汎用性がない。→「他を隠す」というより「代表的なものがある」と考えると問題ない。

設計 Edit


利用者権限を結び付ける際、引数の形式を考えるのが面倒なので、利用者Visitorとしてページに渡す(コントロールクラスが)。

で、ページから利用者を参照、利用者をたらい回し。

側面は見る側が選ぶというのは星。

多くの人か選んだ見解ゲスト向けのデフォルト見解になるというのも星。

見解ごとにそのロールで役立つような機能やフォーム管理者なら連絡用フォームとか)を用意しておけば有意義。

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


利用者情報に「利用者名」または「ニックネーム」を設けて。Twitterでのdisplay_nameになるのはニックネーム?ID?IDは認証に使ったサイト名を含んでいる。

:i/OAuth+ID+表示名

→重複していいので利用者自身が自由に設定。一部でもシステムが決めるのなら非公開に。本人が決めたものではないので。

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


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

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


利用者を分けたときの一番の効果。モード変更なので、他のロールと切り替えて(例えば閲覧者と編集者)使用できないと。切り替えするのは利用者自身。

実装方法は…

†:i/二重ログイン可能[?]

:i/パスワードを複数設定

ログインログアウトだけ?切り替えUIは不要?

ログイン後のログインで。途中のログアウトは不要。

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


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

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


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

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

:/ロールをページ化、利用者を下位ページ化

まとめて管理。まとめて権限設定設定時に権限を要するがまとめておけば利用者ページごとの権限判定にはならない。判定対象はグループページ管理者の間だけ。

:Done/属性継承時の権限判定は?

:i/オープン認証ではユーザーIDにサイトドメイン追加 Edit


アカウントの区別に。IDをグローバルなものにする。

このグローバルなIDは何度アカウントを作り直しても再利用できなければならない。WikiでのIDは使い捨て(再利用しようとすると二世になる)。ここにずれは生じないか?

:i/アカウント削除予約

:i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク Edit


フレームワークを分けてはいけない例。基礎は使われて当然なので、フレームワーク/WikiEngine側とみなしていいかも。

:i/アンケートは自分のページに回答を書く Edit


利用法。他人のための権限設定ページ名。大勢を対象にしてそれを行うには?権限設定ページ名はかみ合ってなくてはならない。

:i/アカウント削除予約 Edit


ページの削除と同じ。ページが消えれば利用者情報も消える。

:i/おかえりなさいメール Edit


「たまには来てよねメール」も。メールアドレスの登録が残っていることを警告しながら存在確認。

:i/Wiki構築には2つの側面がある Edit


管理者向けの説明にはコンテンツに応じたシステムの使い方を。

利用者/ Edit