目次 Edit

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

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

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

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

関連 Edit

 
 

検索:利用者
 

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

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

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

:/利用者クラスの高い依存性

利用者周辺のタグ Edit

Array
 

利用者 Edit


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

アカウント/ユーザーグループ Edit


また、アカウントをまとめて扱いたいときにも利用。

読む人1と読む人2を用意して、権限は同じでも有効期限が違うとか。

アカウント/有効期限 Edit


ログイン状態が続く時間。

ログイン認証 Edit

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

グループロール Edit

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


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

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


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

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


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

…に時間を設定

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


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

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


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

権限(鍵) Edit

利用者/グループ Edit


利用者権限をまとめて操作。

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


管理ページグループ名>ユーザー

管理ページユーザー名 (グループに属さないユーザー

…のどちらも有効に。

要するにカスタマイズ。

ユーザーグループ一覧のページ。あるいは全ユーザーの集約ページ

ユーザーグループ名 - 権限 のリストに○。
名前読み書き
みんな

グループ名はリンクグループを表すページへ。

ユーザーグループページ

ユーザー名 - 権限 のリストに○。

空欄はグループ権限継承するという意味。
名前読み書き
Aさん

:i/検索履歴 Edit

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

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

対象ページはどう指定するか?

:t/?[?]

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

未分類 Edit

見られ方 Edit


見解を利用していろいろな人向けの利用者ページを作成できるように。

元は個人のページ、別見解グループ内での役割を元にした自分のページも作る、というように。

どの見解からも共通する項目(万人共通の客観的な情報)は埋め込みリンクにしておけばいい。自分宛の連絡(コメント)は元のページか独立したページにすれば連絡を取りこぼしたりしない。

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


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

見解は見る側が選択するので、十分な数だけ作っておける。見る側の邪魔にならない。

最もよく使われている見解が新規利用者ゲスト見解になるのも適切。

思い付き Edit

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


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

Atlassian Confluenceはこうなっている。

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


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

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

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


名前は自分で書くこと。

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


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

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


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

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


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

「あなたと似ている利用者は…」 Edit

実装 Edit

:i/情報はページに Edit


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

いろいろな権限 Edit

:i/ページのauthor属性 Edit


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

Tikiの場合 Edit


これらを匿名ユーザー、登録済みユーザーに割り当てられる。

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

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


投稿時のコメント欄(MediaWikiのような)があれば自動署名もあり。
  • 閲覧
    Can view page/pages (tiki_p_view)
  • テンプレート使用
    Can use the page as a tracker template (tiki_p_use_as_template)
  • 画像のアップロード
    Can upload pictures to wiki pages (tiki_p_upload_picture)
  • リバート
    Can rollback pages (tiki_p_rollback)
  • 閲覧/バックリンク
    View page backlinks (tiki_p_view_backlink)
  • 閲覧/履歴
    Can view wiki history (tiki_p_wiki_view_history)
  • 閲覧/WikiTextソース
    Can view source of wiki pages (tiki_p_wiki_view_source)
  • 閲覧/類似ページ
    Can view similar wiki pages (tiki_p_wiki_view_similar)
  • 閲覧/ページの参照?をモジュールやフィードで
    Can view in module and feed the wiki pages reference (tiki_p_wiki_view_ref)
  • ページ名の変更
    Can rename pages (tiki_p_rename)
  • 削除
    Can remove (tiki_p_remove)
  • 凍結
    Can lock pages (tiki_p_lock)
  • メタシンボル編集
    Can edit dynamic variables (tiki_p_edit_dynvar)
  • 編集/ページ
    Can edit pages (tiki_p_edit)
  • ページ操作に関わる権限割り当て
    Can assign perms to wiki pages (tiki_p_assign_perm_wiki_page)
  • 編集/ちょっとした更新として保存
    Can save as minor edit (tiki_p_minor)
  • 閲覧/会話
    Can view contributions to a page (tiki_p_page_contribution_view)
  • 閲覧/許可されていないプラグイン
    Can view unapproved plugin details (tiki_p_plugin_viewdetail)
  • 許可されていないプラグインの実行
    Can execute unapproved plugin (tiki_p_plugin_preview)
  • 許可されているプラグインの実行
    Can approve plugin execution (tiki_p_plugin_approve)
  • Wikiの管理
    Can admin the wiki (tiki_p_admin_wiki)

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


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

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


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

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


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

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


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

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

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


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

でも見解は他の見解を隠すためのもの。汎用性がない。→「他を隠す」というより「代表的なものがある」と考えると問題ない。
  • DB 任意のクエリー実行?
    Can execute arbitrary queries on a given DSN (tiki_p_dsn_query)

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

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

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

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


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

:i/OAuth+ID+表示名
  • 添付ファイル一覧関連の権限割り当て
    Can assign perms to file gallery (tiki_p_assign_perm_file_gallery)
  • Directory Batch Load使用
    Can use Directory Batch Load (tiki_p_batch_upload_file_dir)
  • ダウンロード
    Can download files (tiki_p_download_files)
  • 編集/添付ファイル
    Can edit a gallery file (tiki_p_edit_gallery_file)
  • ZIPアップロード
    Can upload zip files with files (tiki_p_batch_upload_files)
  • 添付ファイル一覧
    Can list file galleries (tiki_p_list_file_galleries)
  • 添付ファイル管理
    Can admin file galleries (tiki_p_admin_file_galleries)
  • 閲覧/添付ファイル一覧?
    Can view file galleries explorer (tiki_p_view_fgal_explorer)
  • 添付ファイルのパス閲覧?
    Can view file galleries path (tiki_p_view_fgal_path)
  • 閲覧/添付ファイル
    Can view file galleries (tiki_p_view_file_gallery)
  • アップロード
    Can upload files (tiki_p_upload_files)
  • 添付ファイルのギャラリー作成
    Can create file galleries (tiki_p_create_file_galleries)

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

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


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

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


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

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

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


認証方法の考え方。既存の所有権と関連付けることが認証
  • User can administer modules (tiki_p_admin_modules)
  • Can admin mail-in accounts (tiki_p_admin_mailin)
  • Can delete his/her own account (tiki_p_delete_account)
  • Can admin integrator repositories and rules (tiki_p_admin_integrator)
  • Administrator, can admin banners (tiki_p_admin_banners)
  • Can view integrated repositories (tiki_p_view_integrator)
  • Can change the categories of the object (tiki_p_modify_object_categories)
  • Can view site stats (tiki_p_view_stats)
  • Can view referrer stats (tiki_p_view_referer_stats)
  • Can ban users or ips (tiki_p_admin_banning)
  • Can admin the dynamic content system (tiki_p_admin_dynamic)
  • Trust all user inputs including plugins (no security checks) (tiki_p_trust_input)
  • Can use the importer (tiki_p_admin_importer)
  • Can view action log for users of his own groups (tiki_p_view_actionlog_owngroups)
  • Can use HTML in pages (tiki_p_use_HTML)
  • Can send a link to a friend (tiki_p_tell_a_friend)
  • Can subscribe to groups (tiki_p_subscribe_groups)
  • Can search (tiki_p_search)
  • Can share a page (email, twitter, facebook, message, forums) (tiki_p_share)
  • Can report a link to the webmaster (tiki_p_site_report)
  • Can view action log (tiki_p_view_actionlog)
  • Can view site templates (tiki_p_view_templates)
  • Can edit translations and create new languages (tiki_p_edit_languages)
  • Administrator, can manage users groups and permissions, and all features (tiki_p_admin)
  • Can edit menu option (tiki_p_edit_menu_option)
  • Can admin cookies (tiki_p_edit_cookies)
  • Can clean cache (tiki_p_clean_cache)
  • Can remove association between two pages in a translation set (tiki_p_detach_translation)
  • Can create new css suffixed with -user (tiki_p_create_css)
  • Can edit site templates (tiki_p_edit_templates)
  • Can edit menu (tiki_p_edit_menu)
  • Can access site when closed (tiki_p_access_closed_site)
  • Can invite user to my groups (tiki_p_invite_to_my_groups)
  • Can admin mail notifications (tiki_p_admin_notifications)
  • Can admin users (tiki_p_admin_users)
  • Can edit object permissions (tiki_p_admin_objects)
  • Can admin external feeds (tiki_p_admin_rssmodules)
  • Can admin toolbars (tiki_p_admin_toolbars)

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


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

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

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

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

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

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


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

このグローバルなIDは何度アカウントを作り直しても再利用できなければならない。WikiでのIDは使い捨て(再利用しようとすると二世になる)。ここにずれは生じないか?
  • View page backlinks (tiki_p_view_backlink)
  • Can view wiki history (tiki_p_wiki_view_history)
  • Can view similar wiki pages (tiki_p_wiki_view_similar)
  • Can view source of wiki pages (tiki_p_wiki_view_source)
  • Can view in module and feed the wiki pages reference (tiki_p_wiki_view_ref)
  • Can remove (tiki_p_remove)
  • Can lock pages (tiki_p_lock)
  • Can save as minor edit (tiki_p_minor)
  • Can admin the wiki (tiki_p_admin_wiki)
  • Can edit dynamic variables (tiki_p_edit_dynvar)
  • Can edit pages (tiki_p_edit)
  • Can assign perms to wiki pages (tiki_p_assign_perm_wiki_page)
  • Can view contributions to a page (tiki_p_page_contribution_view)
  • Can approve plugin execution (tiki_p_plugin_approve)
  • Can upload pictures to wiki pages (tiki_p_upload_picture)
  • Can use the page as a tracker template (tiki_p_use_as_template)
  • Can rollback pages (tiki_p_rollback)
  • Can rename pages (tiki_p_rename)
  • Can execute unapproved plugin (tiki_p_plugin_preview)
  • Can view unapproved plugin details (tiki_p_plugin_viewdetail)
  • Can view page/pages (tiki_p_view)

情報はページ Edit


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

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

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

エクスポート/インポートが容易になる。

管理者定義 Edit

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


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

キーワード:OpenID

高い依存性 Edit


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

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

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


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

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


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

アカウント Edit


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

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

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

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


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

定義の書き方 Edit

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

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


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

利用者/ Edit


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

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

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

有効期間 Edit


有効であり続ける条件
  • 最終使用時刻(最後にアカウント情報が参照された時刻)からの時間が有効期限内
    アカウント情報を使わないような操作が続くと無効になる?→別にいい?
  • 同一端末を使っている
    同じIPアドレス。同じUAかどうかは不要。

    はてなでもやっている?

    これがあると不便?PCで編集しながら携帯での見え方をチェックすることができない。

無効になる条件

利用者属性 Edit


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

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

非公開編集 Edit


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

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

設計 Edit


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

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