Community Auth Token Name Issue

- "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.

Expert Website Development - Temecula, CA
Community Auth For CodeIgniter 3