Welcome Guest, Not a member yet? Register   Sign In
Community Auth Token Name Issue

I have 2 CI installations, and I've gotten one working perfectly but not the other.  The only thing that stands out as big differences between the 2 is that one has SSL certificate installed. 

I'm loading the form with the MY_form_helper, but it is inserting a hidden field with a token with name="token" instead of name="loginToken". 

What can I do to make sure the hidden field is named properly? 

Thank you to anyone who has ideas for me

The token name is usually changed in the setup_login_form method inside Auth_Controller. If you are somehow bypassing this method, you’ll need to set the token name before calling form_open.

Thanks skunkbad, I had forgotten about calling that method in my login controller.

By the way, for people asking about Community Auth, I'm going to be suggesting that they look at, test, and possibly help out with my new authentication package, which is currently something that I've been developing. The new package is called "PHP Universal Authentication", and it's meant to have "adapters", and the idea is that it would allow people to use it with any framework, or even without a framework. I was going to start a CI4 adapter, but CI4 is not complete enough, so I've just been working on a CI3 adapter.

For people who are using CI4, or testing CI4, as soon as possible there will be a CI4 adapter.

Bitbucket: https://bitbucket.org/skunkbad/php-unive...entication
Packagist: https://packagist.org/packages/skunkbad/...entication

It's still early in development, so it doesn't have all the features of Community Auth. That might be a good thing, because some people think Community Auth is too complex.

Just took a quick look at your new Authentication package. And it looks much cleaner.
First of I just want yo say thank you for your work with Community Auth, I'm currently implementing it in a projekt. But for my use your roles, groups and ACL are too limited (or I don't see how I should do it...) for me.

I'm using it like this (with a UI):
1. Create a Group based on these types: [position, department, security]
2. Assign Position(s) and Department(s) to a Menu. (Security are for admin menus)
3. Assign ACL to a User [Create, Read, Update, Delete, Folder] to a specific Position/Department.

So that I can unlock a menu based on the users ACL of that specific Group. Users can be in multiple Groups, so that you can unlock e.g. Delete documents on on only two menus and Create permissions on ten.

(09-01-2018, 02:42 AM)jreklund Wrote: ... your roles, groups and ACL are too limited (or I don't see how I should do it...) for me. ...

As described, it sounds like you are using Community Auth how it was designed. You mention it being too limited, and it would be great if you told me what those limitations are, and also what you would like to see in this new authentication package.

(This post was last modified: 09-01-2018, 12:11 PM by jreklund.)

Here's how I'm building it.

Position, department and security are a group type. And I'm loading different acl_categories based on type.

   IT [position]
   Marketing [position]
       menu.update (this ACL can change your documents as well)
   Sweden [department]
       menu.read (You can only be a member, using the menu.read for member here)
   Sysadmin [security]
   Economy [position]
   Norway [department]
   Useradmin [security]
Main-menu-name [IT,Economy,Marketing,Sweden...]
   (Sub-menus here)
   Economy [IT,Economy,Sweden,Norway]
       (folders here)
       Folder1 [IT]
           (These documents are only I able to see)
       Folder2 (no group specified, using parents group)
           (Both you and I can see these documents)

Here is what I found limited.

ACL can only be assigned to a user.
- I need to create ACL access on groups. So that I can assign menus, folders, documents etc to a group. 
- I then assign users CRUD to that specific group. So it will give me Delete access on some documents, but not all.

Levels and roles + Groups
- I need to be able to have ~3000 groups. So I guess I would have to create (generate from db) an array of 0-5000 with e.g. IT, Economy etc in your $config['levels_and_roles']. And assign value 4319 (or w/e it have been incremented into) to a user, as it can't be a duplicate.
- Change $config['groups'] so that it would be $config['groups'] = '4319' => '10,154,890,2940' so that one user can be in multiple groups.
- Now I can somewhat use require_group() to see if they are in multiple groups. But it would be very hard to track.

I would also need to assign CRUD (up to 4pcs action_id) on every menu item (e.g. 30 pcs) = 4 x30 = 120. So I need 120 action_code's and assign them to a user. And I got around 500 of them. 60 0000 for just menu items. :-)
And that's not something you can create a if statement on. As everything are dynamic.

So now I got
acl_categories [menu]
acl_actions [create|read|update|delete]
acl_users_and_groups [user_id,group_id,action_id | ... ]

Now I only need to assign a user to a group and define CRUD.

Now I can use acl_group_permits('menu.read', $menu_groups, $menu_id) and it will check if my user are in that group and have read permissions. If It can't find a group, it will look for a user_id and object_id (also stored in acl_users_and_groups). So that I can store user specific CRUD for a specific menu item.

Hopefully this will make this clearer on how I'm building my SAAS application with multiple companies (with ~10 users) that are naming their Groups, Menus, Documents etc all different.

So for everyday use I would like to see a:
acl [user_id,group_id,action_id]

*I skipped this and used menu.read as membership. But that's not really good for general usage.

So that you can assign ACL to a group and not to every single member.
Personally I would get rid of "Levels and roles" and "Groups" as they are right now. Maybe leave just "Roles" with admin, manager, customer for small application usage. And not forcing the user to use require_min_level() for checking if you are logged in.

I have also made some small changes here and there, but at this time of writing I can't think it will have any impact on general use. Just modifying it into my application. 
- Stripping out: tokens, serialization, encryption, cookie, require_min_level, require_group, require_role etc

A taste of how my controller looks for my attached image.
I'm using UUIDv4 for all auto_incremented values. So that a user can't guess another group_id, action_id etc. And I'm of course checking that they match what the controller generated.  

PHP Code:
    public function groups$user_id )
$this->data['user'] = $this->user_model->get($user_id);
        if( empty(
$this->data['user']) ) { show_404(); }
$this->data['user']->company_id !== $this->auth_company_id ) { show_404(); }
$this->data['acl_menu'] = $this->acl_model->get_like'menu' );
        if( empty(
$this->data['acl_menu']) ) { show_404(); }
// unset($this->data['acl_menu']['all']);
$this->data['groups'] = $this->group_model->get_all();
        if( empty(
$this->data['groups']) ) { show_404(); }
$this->data['acl_menu_checked'] = array();
$validation_rules $this->_get_rules_groups();
$this->form_validation->set_rules$validation_rules );
$this->form_validation->run() === TRUE )
// What groups are we expecting
$groups array_merge(
// Grab multiple ACL fields
$acl $this->acl_model->_get_acl(array(
// Make sure that "read" action are always selected for a group 
$acl $this->acl_model->_acl_action_code_required($acl$this->data['acl_menu'], 'read');
// Validate ACL. Show 404 in case a user have changed the values.
if( $acl === FALSE) { show_404(); }
// What groups have we received
$acl_groups array_keys($acl);
// Validate groups. Show 404 in case a user have changed the values.
if( !empty(array_diff($acl_groups$groups)) ) { show_404(); }
// Make an ACL array so that we can just save it
$data $this->acl_model->_get_data_user_group($user_id$acl);
// Save ACL
if ( $this->acl_model->save_user_group$this->data['acl_menu'], $user_id$data ) !== FALSE )
redirect('admin/users/groups/' $user_id);


Line: 309

You need an exit; here to force a redirect. Some pages that I have made started to run and crashed with 404.

Attached Files Thumbnail(s)

@jreklund, I appreciate your thoughts and the time you took to write about your experience with Community Auth, and improvements that can be made. As of right now, none of the ACL features have been worked on for PHP Universal Authentication. Keep in mind that I do want it to be as flexible as possible, but not make it so hard to use that people in general are put off by it.

You can probably tell, because I can see that you've got a deep understanding of how Community Auth works, that PHP Universal Authentication is similar. Not saying you should, but if you would like to help with the new project, I'd be glad to have that help. I'm generally working more than 50 hours per week, and have a family life, so sometimes free time to develop is rare.

I've found my user level ACL to be very useful, but I'm never working on websites that have as many users and groups as you describe. Whatever happens, I want the usage to remain as simple as possible. I agree that some of the stuff you stripped out doesn't even need to be in Community Auth. PHP Universal Authentication should be better, and hopefully be something we can use in any framework. I love the idea of being able to move from framework to framework and still have the same auth package. It makes using it really easy after the basics are learned.

Your welcome. That's the least I could do as I have saved plenty of time utilizing free software. Yeah, I saw that ACL and Groups were one of the missing part of the new library. That's the hardest part. Making something easy and flexible with a lot of mussel.

Indeed, there are lot of similarity of them both. Why fix something that ain't broken. But there are much more modern approach with e.g. namespace, interface and use. I have personally never written a library from the ground up, just modified some. So have never used all those new fancy stuff.

Two years ago I started to give back on some community project. Making pull request and not just fixing it for myself. Quite rewarding to actually get an Issue on a project, so that you see people actually using it. As of right know I need to make this version go live at the end of september before I can do anything else. Hopefully I will have everything done by then. After that I can see if we can port/rewrite anything for the new library, if it fits the new roadmap.

It sure is. My community project only got three roles admin, writer and guest. So it would have worked perfectly fine, except that I don't have any PHP framework (Codeigniter). It's a custom built one (not a framework, just code) that I have made some improvements too. I'm now looking over to start utilizing a PHP MVC framework and rewrite the project from scratch. But everywhere I go its too small or too big for the project... Slim looks good. But there are no native support for MVC.

It's not everyday you need to write something with all these customization's regarding modular design. So simplicity will match more people. Do you have a roadmap somewhere? Maybe I'm too tired (01:49 now) but I can't figure out how to use it with CI.

One more thing that can be useful. Have you thought about implementing a Oauth similar API so that you can make a bridge between two applications for SSO?

- "Why fix something that ain't broken?" - because it only works with CI3, and I want it to work with CI4, Slim, Lumen, frameworkless projects, etc.

- "I have personally never written a library from the ground up" - It will give you a real appreciation for planning ahead.

- "Slim looks good. But there are no native support for MVC." - I know Lumen is only meant to be used for APIs, but I've used it for more. I don't want to go as far as to say I recommend it, but its Slim++;

- "I can't figure out how to use it with CI" - Maybe we could have a Skype session soon. There are no docs yet, but 5 minutes on the phone would get you going, and I wouldn't have to type out something that may change.

- "Do you have a roadmap somewhere?" - No official roadmap or milestones declared, but here's what I'm thinking:

- Requiring min level or verification by level should go away. It's legacy garbage that I never use, and I really don't want to use it. It'll be ripped out soon.

- I'd like for users to be able to be assigned more than one role. This has been a limitation of Community Auth, and even before I work on ACL, I want to work on this. For instance, a user with role "employee" might be a "customer" too. This means that there is a need for a user_roles table. Every user should have at least one role, but they may have more.

- Just like the user_roles table I am proposing, there should also be a user_groups table. Users should be allowed to be assigned to multiple groups. For instance, an admin might be part of a group named "3rd shift" for employees that work at night, but that really has nothing to do with that admin's role. Same for a group of users that work at a specific location, such as "store #13". That said, I'd still want to retain how groups work now in Community Auth, where roles could be grouped. I don't think this has to be hard to implement, but we might end up with 2 groups related tables, user_groups and role_groups. I really don't want a group_groups table, because that could get really messy, and I'd really rather not need to do recursive queries to see if a user is allowed to access something because they are in a group that is in a group that is in a group, etc, etc. Open to ideas here.

- If a logged in user for some reason tries to access a page that they shouldn't have access to, Community Auth would log them out and show them the login form. That's fine, but maybe it should tell them why. Even something as simple as "You were logged out for trying to access a page you didn't have proper privileges to access. Also, when this happens, I believe Community Auth's redirect would point them back to the page they shouldn't be able to access, creating a infinite loop of not being able to login, and then eventually being put on hold. This should never be allowed to happen.

- In general, if it was something I feel was an important thing in Community Auth, I want it for the new package, as long as it isn't specifically for CodeIgniter. Remember that I want this to work anywhere. At the same time, I am trying to simplify usage and make things easier to implement. I don't want a 13 point install process anymore. It would be awesome if it were like 5 or 6. People screwed up the Community Auth install process way more often than you would believe.

- Regarding ACL, my initial solution was to solve a problem when a role wouldn't normally by allowed to access something, but I wanted to give a specific user with that role the ability to have access. It was never meant to be the other way around. What I mean by that is that if the role was normally given access to something, I didn't want to use ACL to restrict a person with that role. This is why there is only an acl_permits method, but not acl_denies, because by default if the person didn't have an ACL record for a specific ACL category + action, then they wouldn't have any special privileges for that category + action.

I want to point out that I feel your pain. I've had to use my own ACL solution enough to know that there are limitations, and the big one is that ACL should be able to be used to deny somebody access. It should also be enhanced so that it applies to groups. Example is that I have a new employee, but they are so new that I don't want them to be able to do X,Y and Z until they complete training. If authentication would normally allow access for employees, I'd like to be able to do something like:

PHP Code:
if( $this->requireUser('employee')->notLimitedBy(['tasks.X']) )
// Some employee thing, but make sure employee doesn't 
        // have a restriction/limitation for tasks.X

Might also be nice to be able to do something like this:

PHP Code:
if( $this->requireUser('admin')->orAclPermits(['admin.foo']) )
// Some admin thing that admins can do, but also anybody with ACL for admin.foo

- "Have you thought about implementing a Oauth similar API " - I haven't thought about this. As you're aware, Community Auth has a way to force login, (https://community-auth.com/documentation...rced-login), and I'm not sure I want to do a whole lot more than that, or at least not until I get everything else I talked about here done.

Theme © iAndrew 2016 - Forum software by © MyBB