Joomla! Discussion Forums

Maybe it's been too long since I worked with Joomla groups but I'm trying to find the right API call to determine if a users is a public, registered, or special user.  I need to know this so that I can make a check against a record's access permission, where 0 is public, 1 is registered, and 2 is special ( same as jos_content ).

This is the code that I thought that I would use.


The admin's group is 25, however, so this doesn't work.

com_content's frontend model uses this type of logic and it doesn't make sense to me.  For example, in the method _buildWhereClause() around line 175 I have this code.


On the frontpage $gid is show as '25'.  The problem is that access will never be "25".  It will be either 0, 1, or 2.  A registered user's group is 25, so changing the article's access to special will not hide the article from a normal, registered user (screenshot attached).

Here is the info in the db.


So although there are numerous examples of using $user->gid to check table.access, it looks like this practice is faulty.  So what exactly is the best way of checking table.access?

I know that the ACL topic is hotly contested but there really does need to be a simple API that one can call to check if a user is a normal user or a special user.  Even a JUser::isRegistered() or JUser::isSpecial() would be better than nothing.

Please let me know if I'm doing something wrong.

tcp

Any suggestions about to check the group and access level of the current user?  It seems like the best solution would be to add several methods to the JUser class so that a developer could do something like this.



I suppose that the table jos_core_acl_aro_groups is the ultimate authority on groups and group ids, and that this table needs to be checked.  Perhaps the table could be read once, then the gid of the user could be compared to the a static result array.


This may be a better approach over using the JAuthorization API because only a single query call is need to determine all group information.

I would be willing to write some code but I'm still waiting for reviews of code that I wrote weeks ago, so perhaps this isn't an issue for most people.  Certainly one reason for the relative silence around here is that Devs are busy with the 1.0.12 release. 

As far as I can tell, the current access checks in many of the core components are broken because they compare the access level in the table ( jos_content, for example ) with the gid of the user ( which will be 18 or 25 ).  Please correct me if I'm wrong.

I'd love to hear about alternative ways of approaching this problem.  I don't have any problem pursuing my own implementation but I think this is a major issue for the framework.

tcp

If I remember correctly, in 1.0.x, the frontend has $my->gid = 0, 1 or 2, the backend has $my->gid = 17 - 25.
I suppose it's the same with $user in 1.5

Try the following code on the frontend.


When logged in as admin on the frontend, I get the following.


It's been a while since I worked with the 1.0 code so I can't say if this is a change or if it always was this way.

tcp

Attaching the code that I'm currently working with until something else better comes along.  Basically, it demonstrates various is*() functions, such as userIsRegistered() and getHighestUserAccessLevel().  Ideally, these methods would be incorporated into the JUser class and could be called like $user->isRegistered() and $user->getHighestUserAccessLevel().  That would allow one to do something such as this.



Although I simply coded the gids into the getGroupIDsForGroup() method, the final impelmentation would need to read the group acl table, parse the information, and store the results into a static lookup table.  It could work like this ( steam-of-thought code ).



So, one DB call, build the lookup table incrementally, and all should be good.  Well, that's the ideal anyways.

Few quick notes.  No, this doesn't addess the topic of ACLs.  This simply provides an (proposed) API for JUser to help identify the user's group so that one can perform simple access checks based on the old Joomla notion of group id.  Additionally, I work on PHP5 so this code doesn't return proper references under PHP4 and any implementation of the code should do so.

Well, "you like" ?

tcp

There's definitely a bug: $my->gid using legacy mode is different from $my->gid in 1.0.x



$user in 1.5 has the same behaviour, but perhaps this is intentional?


Perhaps a dev can comment on this?

Just wanted to let you know that a solution for this one is in the works. You are right about the differences between 1.5 and 1.0, it slipped below radar. Using the oppurtunity todo a bit of refactoring in the way we handle users inside the system.

I don't think we need a complex solution at the moment ( ACLs will come in a later release according to the roadmap ).  The current system supports three basic access groups ( Pub, Reg, and Special ) that are often used to check access and there needs to be a way to:

• Determine if $user is pub, reg, or special;
• Determine if $user is an administrator;
• Determine which subgroup a $user is member of ( author, editor, publisher, manager, etc... );
• Determine the highest access level so that one can code the access check into SQL ( eg, jos_content.access <= $access ) .

Finally, it needs to be easy.  The authorize() method doesn't seem to help me understand what type of user I'm working with and looks overly complex for a simple task of "tell me if this user is an Author".

Ideally, this API should work with other groups defined by the admin or by 3PD extensions.  I'm thinking of the likes of AccessGranted.

My suggestion was to add additional methods into JUser.  Please feel free to look at my code, but I would be happy with any solution if it offered an API to help 3PDs work with groups.  I'd also be available to help test any changes, so let me know what I can do to help.

tcp

I'll do

I have fixed this issue in the SVN, an aid dynamic variable has been added to the user object. This 'aid' which stands for access identifier acts in the same way as the 'gid' in 1.0. When switching legacy on the $my variable now behaves in a consistent BC way.

I'll give a look as soon as the tree works - Rev 6150 is seriously broken. 

Hi,

I'd like to get this written up into a "How To" on the dev wiki.  These are likely to be frequently asked questions so I think it's important that the info is readily available.

Could someone (tcp?) spare a few minutes to gather the basic details together?  Something along the lines of:

1. How to determine if a user is logged in.
2. How to determine group access.
3. How this differs from 1.0.x.

If you'd like to write the whole thing that's okay  , but I can flesh things out myself if I'm certain of the basic details.

Thank you.

Regards,
Chris.

@TCP : Try a reinstall, seems to work fine on my end and make sure you clean your sessions. This error is a typical session problem since the user isn't present in the session yet.

@Chris :

It works almost in the same way as in 1.5 with the expection that we now have two extra (dynamic) user paramaters. A quick overview :

- aid : defines the user access identifier and acts in the same way as the gid in 1.0 (normally this is 0 for for public, 1 for registered and for for special). The aid is used against the systems access database fields to define if the user can access a certain database resource.

- gid : defines the actual acl user group identifier (19, author, 20 editor, 22 publisher, 23 manager, 24 administrator, 25 super administrator).

- guest : defines if a user is logged in or not (when logged in guest is 0)

Note : aid en guest are dynamic parameters which are set at runtime by the application. They don't exist on the framework level and are additions to make things a bit easier until we have a full ACL implementation.

Developers are encouraged to user the JUser::authorise setting when doing checks against the ACL instead of relying on directly on the gid.

Is this enough to get you started ?

Johan

Thanks Johan, I'll take a stab at it and let you know if I hit any problems.

Regards,
Chris.

Sure.  I'll follow-up using the Documentation forum.

tcp

Jinx, thanks for looking into this.  I did some tests and $aid doesn't seem to be working so well.  Am I doing this right?

Code:


Frontend, not logged in:

Current user is ok, but what about the access for $user2?

Frontend, logged in as admin:

User is an author, but no access.

Backend:

Same.

Using JUser::authorize(), how can I check if the a user ( JUser->load(#) ) belongs to one of the admin groups ( Manager, Admin, Supa ) ?

Overall, I really think any solution needs to be implemented in JUser, not JApplication and JFactory.  This may be the reason why my results are inconsistent.  Personally I think my solution is a bit more graceful because it doesn't rely on JUser::get(), so the internal implementation can be changed when ACLs are implemented.  Yeah, it's a short-term solution but it's a solution to a real problem and the encapulation works to the framework's advantage in the long-term.  Once you start offering JUser->get('aid'), it's there.  Please give a look at my code which kinda shows the concepts that I'm suggesting.

tcp

Quick reply :

The second test your are doing will not work since the 'guest' and 'aid' parameters are dynamic and created at runtime by the application. If you load a user he won't know about 'guest' and 'aid'. The reason 'aid' is created at runtime is to mimic the behavior of 1.0 and to make it easy to remove it again in future version. The 'guest' parameter is also dynamic because we don't have a field to store it in the database and we also don't have a relation between the sessions and the user table. If you want to know if a user is logged in, we could consider allowing a relation between the session and user table based on user id.



The ACL we are moving towards isn't a role based system. It doesn't matter what group your users belongs too, all that matters is if your user is authorised to preform a certain action against a certain object. While your solution does indeed provide further possibilities it also uses a role based concept, implementing it would only makes things more difficult in the future.

Got it, at least conceptually.  Practically, people will need to perform access checks in J 1.5+ until ACLs are fully implemented.  Would it be better to move the dynamic generation of aid, access, and guest to JUser so that all JUser objects work consistently?

That makes sense, you wanna have a look at that ? My list is already quite full at the moment. Need to implement your JToolTip work first

Where is the code that sets 'aid'?  I grep'ed for 'aid' and only found the $user->set() call. 

tcp

It's in the user plugin.

Attaching the diff from my first attempt.  Basically, I added a number of tests to the JUser::get() method to detect for the special attributes such as 'aid', 'admin', etc....  I think this provides some useful functionality in the J 1.0 sense of things.

The diff is based on revision 6221.  I tested using PHP 5.1.something.  ???

To test the code, I used the following code.


It produces the results that I would expect.


After looking at and working with the code, I can say that there is still a lot of work to do and it should be interesting to see an ACL implementation in J 1.6.  In the meantime, the current framework is excellent.

Feedback always appreciated.

tcp

Edit: Forgot to mention that I added a method named getGroupData() which returns a Stdclass object with group information ( basically jinx's code from the user plugin).  Although this can work ok as a protected method, what I would really like to see is a simple method ( eg, JUser::getGroup() ) that returns group information for the given user.  The information returned could be an object of JTableAroGroup or "JGroup".  Even an initial implementation may be out of the scope for 1.5, but it would be nice to have an interface to JAuthorization where I could code something like the following.


Probably a can of worms.  Well, food for thought.