Hi all- I’ve been working on a number of Addins, and I try to keep them “configuration lite”, but a frequent need is to know the current logged in user. See for example my Visits library, which doesn’t no Auth of its own but would like to record any logged in users with the traffic record. Currently I handle this by checking $_SESSION[‘user_id’], and supplying a config file so folks can provide their location. But working on anew library with the same issue has me wondering:would it be useful to have CI store the userid after login, accessible as a core service or config?

CI has always been pretty adamant about not having an authentication lib because they don't want to be that opinionated. It's pretty simple to store the user_id in the session, redis, database, or wherever you want. If you're looking for an overall authentication library that handles the current user state, I'd take a look at https://community-auth.com/ (Note, i've never used it but i know a lot of people have)

Codeigniter is simply one of the tools you need to learn to be a successful developer. Always add more tools to your coding arsenal!

I'm precisely *not* looking for an authentication library, as well as agreeing that CI shouldn't include one, but rather recommending CI have a standardized means for accessing a user ID or unique identifier that authentication libraries could set and other libraries and code could rely on. The problem as a library developer is that if I don't bundle some authentication within my library (which is a terrible solution) then I can't reliably know if a user is logged in or how to identify that user, because every authentication library out there may have their own way & place to store it. Typically it probably shouldn't be CI's job to 'curate' this kind of info, but "current user" is such a core concept I think it may have a spot.
Store where... Probably as a config value that is set on=the-fly and optionally accessed through a service? just a guess.

(04-05-2019, 11:33 AM)MGatner Wrote: I'm precisely *not* looking for an authentication library, as well as agreeing that CI shouldn't include one, but rather recommending CI have a standardized means for accessing a user ID or unique identifier that authentication libraries could set and other libraries and code could rely on. The problem as a library developer is that if I don't bundle some authentication within my library (which is a terrible solution) then I can't reliably know if a user is logged in or how to identify that user, because every authentication library out there may have their own way & place to store it. Typically it probably shouldn't be CI's job to 'curate' this kind of info, but "current user" is such a core concept I think it may have a spot.
Store where... Probably as a config value that is set on=the-fly and optionally accessed through a service? just a guess.

It seems to me that your library would depend on access to an instance of whatever authentication class the developer is using. Instances would be passed to your constructors or defined by a setter method in your library. Then you need "callables" to the appropriate methods that would return the item you need - be it logged in status or a user id. I see these as config items - essentially strings that are the names of the appropriate method in the class you're depending on. e.g.

PHP Code:

public $isAuthenticated = 'isLoggedIn';public $UID = 'getUserID';

This seems to satisfy your need and not require a framework-wide property of debatable value.

Obviously, the third-party authentication library must have - or be extendable enough to allow adding - methods that return values you can use.

I believe you are making my point for me. While that solution definitely works, it still requires either a) every authentication library to implement the same method/property/export/etc, or b) my library to guess or be configurable to know how to get that info from the selected authentication solution. For CodeIgniter to have a central, standardized location to get/set this still puts none of the burden on the framework for determining the info, but provides a consistent and reliable way for developers to pass the info between each other in the absence of external standards.

Basically, they prescribe a Subject (something for which access control might be appropriate), a Principal (something or someone who might deserve access to a Subject), a Credential (some proof of identity).

Authentication tools would provide a LoginContext (with callables or callbacks), or an adapter with one could be made.

It sounds like the earlier part of this thread is waltzing around the notion of a Principal, and how to determine if same is "logged in". It doesn't seem to address the notion of role-based access control, which seems to me to be the primary reason for going down this road.

My worry is that any solution requires that the problem be identified & agreed to (it may not just be a userid), and that alternatives be considered. This issue has come up before, and been argued for/against, without a consensus being reached.

Would what you are suggesting work with any of the "common" auth packages that are used with CI? with minimal adaptation needed?

Yes, I think what I am proposing would be compatible with any authentication module, with little or no alteration. The point isn’t so much to hook the *services* performed by authentication and authorization (leave those to the libraries) but to curate the *results*. What I’m interested most specifically is a way of identifier “current user” independent of the module or library used to determine that user, so (I think I might have said this already) for example I could populated a “created by” field on a completely unrelated module.

I’ve been thinking on how I would do this if I did it myself (and might send over a PR as an example), but I’ve been thinking a simple set/get method to the session library along with predefined events. Then a module could call session()->user($loggedInUser) or $event->trigger(‘login’, $loggedInUser) and the framework would handle everything for other modules.