salamanderさん、こんにちは。
相変わらず鋭い指摘ですね。
引用：
グループに属さないユーザが特権(?)を持てないようにするパッチ当てたり各ユーザの権限確認していた時に、ユーザの
作成/編集で「承認ユーザでもゲストグループに所属できる」と言う事が気にかかりました。
今までは、「ゲストグループは未登録ユーザ」と思い込んで運用してきたのですが、「ゲストグループ」とはどのよう
な取扱いを想定されていたんでしょうか?
# 運用的には各グループのポリシーをしっかり立てていれば問題無いのですが、「登録されたユーザなのにゲストだ」
# と言うポリシーが可能だと言うことがスッキリしなかったで質問させていただきました
私も変わったポリシーだな、と思います。
X2互換、という前提であれば、groupid=3に登録ユーザが所属しうるという状況はおかしいでしょう。
ただ、その設定をうまく使えば、複雑な権限設定がスッキリする可能性もあるので、単純な機能追加だと考えることもできなくもないでしょう。
いずれにせよ、本当の回答は、minahitoさん以外からは得られない気がします。
sf.netフォーラムに書けば、minahitoさんの回答率高いと思いますよ。
# 新質問へのリンクURIだけ張っておけば、マルチポストなどと非難されないでしょう。
もしくは明日、大久保で直接問いただす、とか
GIJOEさま
ご回答ありがとうございます
引用：
GIJOEさんは書きました：
私も変わったポリシーだな、と思います。
X2互換、という前提であれば、groupid=3に登録ユーザが所属しうるという状況はおかしいでしょう。
ただ、その設定をうまく使えば、複雑な権限設定がスッキリする可能性もあるので、単純な機能追加だと考えることもできなくもないでしょう。
いずれにせよ、本当の回答は、minahitoさん以外からは得られない気がします。
sf.netフォーラムに書けば、minahitoさんの回答率高いと思いますよ。
# 新質問へのリンクURIだけ張っておけば、マルチポストなどと非難されないでしょう。
う〜ん。確かに完全に閉じた環境でサイト運用している場合なんかでは、権限設定がスッキリするかもしれないような…
元ネタの絡みからいけば登録時のリストからゲストと登録ユーザを削除して、強制的に登録ユーザグループにも所属させ
る(最終的なグループは「ユーザグループの管理」から設定)か、何らかの設定ミスで「useridがありながらgroupidがつ
いていない場合のgroupidは2である」となっていれば、新米管理者的には安心できるかなと思いました。
どちらにしても実現するにはuserモジュール回りに手を入れることになりそうなので敷居が高いのですが。
sf.netの方は時間を見つけて覗いてみようかと思います。
salamanderさん、こんにちは。
引用：
元ネタの絡みからいけば登録時のリストからゲストと登録ユーザを削除して、強制的に登録ユーザグループにも所属させ
る(最終的なグループは「ユーザグループの管理」から設定)か、何らかの設定ミスで「useridがありながらgroupidがつ
いていない場合のgroupidは2である」となっていれば、新米管理者的には安心できるかなと思いました。
どちらにしても実現するにはuserモジュール回りに手を入れることになりそうなので敷居が高いのですが。
その動作も候補として上がりましたが、groupid=2 に特別な意味を持たせるサイトがない保証がないので、コアのコードとしてはどうかな、と私が主張しました。
もちろん、所属グループがなければgroupid=2に強制的に所属させてしまう、という動作が必要な場合でも、おそらくpreload一発です。
http://www.xugj.org/modules/QandA/index.php?post_id=7467このフック先でINSERT文を発行して、いったん強制リダイレクトかな。
GIJOEさん。お世話になっています。
引用：
GIJOEさんは書きました：
その動作も候補として上がりましたが、groupid=2 に特別な意味を持たせるサイトがない保証がないので、コアのコードとしてはどうかな、と私が主張しました。
基本的にgroupid=2を除くすべてに予め特別な意味が付与されているのですから、「groupid=2に特別な意味を持たせることはない(ありえない)」ということが絶対無いとは言いきれませんね。
# 過去にどのような議論がなされてきたかを考えもせずに、意見しちゃってましたね。
引用：
jidaikoboさんのpreloadをよくよく眺めていたら、確かにpreloadで出来そうです。ちょっと考えてみます。
salamanderさん、こんにちは。
引用：
jidaikoboさんのpreloadをよくよく眺めていたら、確かにpreloadで出来そうです。ちょっと考えてみます。
tohokuaikiさん、ですね
グループ所属がなければgroudid=2 に強制所属させる、というpreloadを書いてみました。
preload/DefaultGroupID2.class.php
として保存
<?php
if( ! defined( 'XOOPS_ROOT_PATH' ) ) exit ;
class DefaultGroupID2 extends XCube_ActionFilter
{
var $default_group_id = 2 ;
function preFilter()
{
$this->mRoot->mDelegateManager->add( 'Site.CheckLogin.Success' , array( &$this , 'hook' ) , XCUBE_DELEGATE_PRIORITY_FIRST - 1 ) ;
}
function hook( &$xoopsUser )
{
if( ! $xoopsUser->getGroups() ) {
$db =& Database::getInstance() ;
$db->queryF( "INSERT INTO ".$db->prefix('groups_users_link')." (groupid,uid) VALUES (".$xoopsUser->getVar('uid')." , $this->default_group_id )" ) ;
$this->mRoot->mController->executeRedirect( XOOPS_URL , 5 , 'You are belonging to the default group, now' ) ;
exit ;
}
}
}
salamanderです
引用：
引用：jidaikoboさんのpreloadをよくよく眺めていたら、確かにpreloadで出来そうです。ちょっと考えてみます。
あぁぁ。そうでした。tohokuaikiさま、お名前を間違えてしまい申し訳ありませんでした。
# jidaikoboさまに対しましても、お名前を間違えてしまい申し訳ありませんでした
引用：
グループ所属がなければgroudid=2 に強制所属させる、というpreloadを書いてみました。
preloadありがとうございます。
私が関わっている環境では、「アカウント持ってるのに何で入れんのじゃ」とクレームつけてくるユーザが居そうなのでこのpreload使って運用するのが良さそうです。
引用：
salamanderさんは書きました：
今までは、「ゲストグループは未登録ユーザ」と思い込んで運用してきたのですが、「ゲストグループ」とはどのよう
な取扱いを想定されていたんでしょうか?
亀レスですが、分かる範囲内で書きますと、
XOOPS2 は "グループ" という言葉を使っていますが、システム的にはロールに近いです。管理者は管理者というロールを持っていて、管理者ロールから権限が決定します。同様にゲストはゲストというロールを持っていて、その権限はゲストロールから決定します。
現在認証を受けていないアイデンティティに対して特定のロールが割り当てられることは、システムでは割とよく使うやり方なので、ゲストユーザーがゲストロール（グループ）から権限を決定するという XOOPS2 のやり方はそこまで特殊というわけではありません。
よく開発者の間で問題視されているのは、ゲストユーザーでも認証ユーザーでも透過的に $xoopsUser オブジェクトで扱おうとしていた計画が途中で頓挫してしまった orz ことだと思います。
onokazu さんはゲストユーザーの場合の $xoopsUser は XoopsAnonymous クラス（だったかな？）を使う予定で、開発者側はゲストユーザーについては特別な処理を書かなくても済むように設計は済ませていたのですが、その頃には、!is_object($xoopsUser) でゲストか否かを判定するコードが普及しきってしまっていて、いまさらコアコードを変更できない！ということになり、変更を断念したそうです。これは XCL 2.1 を開発しているときに話を聞いたことがあります。
XC ではその無念を晴らすべく？完全なロールベースに移行しています。現在アクセスしているユーザーは "アイデンティティ"、そのアイデンティティが持つ"ロール"で権限を判定するという概念を持っています。
結果として判定コードも
suin さんが書かれているような違いを持つようになっています。
引用：
minahitoさんは書きました：
よく開発者の間で問題視されているのは、ゲストユーザーでも認証ユーザーでも透過的に $xoopsUser オブジェクトで扱おうとしていた計画が途中で頓挫してしまった orz ことだと思います。
onokazu さんはゲストユーザーの場合の $xoopsUser は XoopsAnonymous クラス（だったかな？）を使う予定で、開発者側はゲストユーザーについては特別な処理を書かなくても済むように設計は済ませていたのですが、その頃には、!is_object($xoopsUser) でゲストか否かを判定するコードが普及しきってしまっていて、いまさらコアコードを変更できない！ということになり、変更を断念したそうです。これは XCL 2.1 を開発しているときに話を聞いたことがあります。
XC ではその無念を晴らすべく？完全なロールベースに移行しています。現在アクセスしているユーザーは "アイデンティティ"、そのアイデンティティが持つ"ロール"で権限を判定するという概念を持っています。
結果として判定コードも suin さんが書かれているような違いを持つようになっています。
minahitoさま
salamanderと申します。
なるほど、「そのロールを与えられたアイデンティティ」との理解でよろしいでしょうか。
その辺の経緯などを含めて、あまり良く判っていなかったので、「ゲストロールは未登録ユーザのみにしか与えられない」と思い込んでおりました。
解りやすいご説明ありがとうございました
登録日: 2008-10-13
投稿数: 23
登録日: 2006-3-20
投稿数: 3708
登録日: 2006-3-20
投稿数: 394
