議事録/部会/2012-5-19 の履歴(No.12)

開催†

2012/5/19(土) 18:00〜 A102にて

↑

部会中の議事録役†

副会長さんおねがいします

↑

内容†

連絡事項

↑

連絡事項†

MLについて再度確認
会費払ってない人払ってね
2年生以上で、お菓子代を井上くんに払ってない人は払ってね

↑

議題†

今回は議題っていうか相談?

調布祭について
調布祭のスタンプラリー(おまけ券)参加の可否について
TeReswikiのアカウント管理についてどうするか
毎月第4土曜に和室交流会しちゃう?
新規プロジェクトの立ち上げ

↑

TeReswikiのアカウント管理について†

どうしましょうか

一応、会長にも連絡しましたが、本当にここのパスをもうばら撒いていいんですか？
せめて夏前ぐらいまでは待った方が良くないですか？
これから辞めてくる人は結構増えてくるわけで、正直夏前までに辞めるような人に公式ページの編集権や会員名簿の閲覧権を与えるのは不安です。 -- 有機酸 2012-05-05 (土) 23:45:20
夏前ってことは7月の総会らへんってことですよね?
なんか自分は1ヶ月ほどで教えてもらった記憶があったので今回も1ヶ月でいいかな?とか思いました。 -- henteko 2012-05-06 (日) 00:01:29
長年の伝統としてパスを伝えるのは夏ごろでしたが、僕個人としては、Wikiを編集し活動意識を向上させる上で、パスを早めに教えるのはいいと思ってます。不安であれば定期的にパスを変更し部会で知らせるとか、 -- P'ce 2012-05-06 (日) 00:10:51
なんらかの措置は要ると思います。まぁ実際それが面倒だったりもするんですが…。パスの変更についてはWeb管的な操作が要りますので、その時に聞いてください。 -- P'ce 2012-05-06 (日) 00:13:31
なるほど、自分の勘違いですね。ではまぁ例年通り7月ら辺でいいかなと自分は思います。 -- henteko 2012-05-06 (日) 22:17:50
というかすっごい前々から疑問だったのですが、なんで個々人にIDの発行しないんですか？後々の管理考えるとそっちの方がいいと思うのですが…… -- ponica 2012-05-07 (月) 07:22:08
yukinohana.netを間借りしているので、ユーザーの追加及び削除が簡単には出来ないのでは -- henteko 2012-05-07 (月) 14:12:39
だったらせっかく部室にサーバー端末置いた事ですしそっちに環境を構築しませんか？ドメイン関係はこっちでなんとかします。最悪メンバーページだけでも。 -- ponica 2012-05-08 (火) 08:19:50
部室のサーバーは外部に公開出来ません(というかやり方が分かりません…) 部室内のネットワークから外部に公開するやり方をご存知なら全然大丈夫ですしありがたいです!! -- henteko 2012-05-08 (火) 22:42:50
少しapacheの理解が足りていなく、ユーザーを分ける件について出来ないと言いましたが、一応現状のyukinohanaでも出来るようですね個別ユーザー名+パスワードのみなら -- henteko 2012-05-09 (水) 00:46:41
まあ多分一番マズイのは会員名簿になると思います。TeResに一瞬でもいれば過去の連絡先とか見放題って状態はちょっと・・・　個別でID作れるなら、一般用にもう一つID作っておいて、大抵の所は一般IDで大丈夫だけど簡単に見られるとダメかなってところだけ特別なIDが必要とか？ -- 有機酸 2012-05-12 (土) 23:18:25
それが一番簡単でいいかもしれませんね名簿の所だけ別アカウントにするのがスマートですね -- henteko 2012-05-13 (日) 14:28:28
なんか名簿外部化とかそんな要素を含んだ話題っぽかったんで一応名簿と別にメンバーリストを作りました。 -- ponica 2012-05-13 (日) 21:47:30
メンバーリストは各メンバーの個人ページへのリンクとしての利用をメインとした名簿と別の物です。 -- ponica 2012-05-13 (日) 21:48:14
てことは、個人ページには外に公開してもいいものを書くって感じでおk？ -- henteko 2012-05-15 (火) 09:18:11

↑

第一案†

TeReswikiアカウント管理第一案

title:アカウント管理システムの構築と導入

rootユーザー:teres 部室サーバー:teresPG

1.簡単に会員のアカウントとパスワードを管理できる
2.簡単に特定のアカウントを凍結(削除?)することができる
3.2は特定のアクションが一定期間無かったら自動凍結するとか?
4.3のアクションは、2ヶ月間wikiにアクセスしなかったらとか? -> wiki活性化の為にもいいかも
5.凍結されたアカウントについては、web管理者がアカウント保持者より申請を受けて、解除する

備考

 1についての案
   部室無線LANよりteresPGにアクセス(ブラウザ経由)して、そこから会員管理をする
   rootユーザーのみが作成、凍結、削除、変更が出来て、一般ユーザーは変更のみが出来る

 teresPG側処理
   アクションごとに、ローカルgitによりバージョン管理をする(一応ね、意味はあまりないかも)
   commitしたら、yukinohana.netの特定URLに、特定POSTを投げかける

 yukinohana.net側処理
   teresPGより、特定URLに特定POSTが着たら、.htpasswdを書き換える

全体的な問題点

 セキュリティー面
   1.teresPGはサークル棟ネットワーク上に存在しているので、多分アクセスしてこようとすれば他サークルもアクセス出来るかも(よくわからない＞＜)
     しかし、上記に関してはパスワードをかけてるので、まぁ大丈夫かな?(rootユーザーか一般ユーザーしか作業自体出来ない)
   2.yukinohana.net側のこと
     特定URLは意味不明な文字列(例: http://yukinohana.net/~teres/kdlfhakjdnvlkajkhsnkgvjankdsjvnajk)とかするけど、これだけで本当に大丈夫なの?
     特定POST以外を受け付けたら何もしない処理も追加するよ!!(POSTのnameも意味不明文字列)
 実現面
 　1.teresPG側の処理は多分出来るけど、yukinohana.net側の処理はperlを用いて書くのでよくわからないかも(かっこいいのでperlで書きます)

このシステムのメリット、デメリット

 メリット
 　1.凍結させる期間によるけど、多分今よりかはwikiの利用が活性化されるのでは?(当社比30%うp)
   2.夏まで残ってたけど抜けちゃったよーとか言う人を完全にwikiにこさせないように出来る
 デメリット
   1.作るのダルい
   2.誰が作るのwwwwwwwwwwww
   3.一回部室行ってアカウント作んなくちゃいけないんでしょ?マンドクセ -> これはweb管理者だけか
   4.本当に必要ですか?

これは一案です。もっといい案があるかもしれませんね。