[eluser]thody[/eluser]
I realize this is a question, which has been asked before, but I think it's time to revisit.
Should CodeIgniter include a core Auth library?
I fully understand, and appreciate the desire to keep CI lightweight, and to only include the most commonly needed libraries in the core. I can't recall where I read this now, but at one point I saw the explanation for why there is no Auth library in CI, and to paraphrase, it was that it was believed that Auth is too application specific, and wasn't commonly used enough to justify increasing the footprint of the framework. Pardon me if I've misquoted, going from my recollection of something I read on here quite some time ago (feel free to correct me).
While there may have been some validity to that statement at one point, I feel it's no longer accurate. I can't recall the last time I built a CI app that didn't require a login of some kind. CRUD for users, and handling logins is an essential piece to nearly every web app, and it deserves a place as a core library. I've noticed that there is a new Cart library in the SVN trunk for 1.7.2, which is awesome, but surely if the argument has been made that e-commerce is an essential component, then an Auth library must be too.
I realize we all have different priorities, but I feel getting a simple, cleanly-coded Auth library in the core benefits us all, and would be a great addition to this awesome framework.
If you agree, I hope you'll reply to this thread to show support. Cheers.
[eluser]jedd[/eluser]
Quote:I realize we all have different priorities, but I feel getting a simple, cleanly-coded Auth library in the core benefits us all, and would be a great addition to this awesome framework.
The fact that several already exist, and most people end up writing their own anyway, kind of answers this question.
I think you were bang on the money with your original observation that it's too application-specific, and similarly it's too author-specific I think. You said that you've written a bunch of CI apps now that all require an auth library, so presumably you copy yours across each time as part of your base install, before cutting any application-specific code.
I guess one question hidden in here is .. where is your library published and what free licence have you slapped onto it?
Perhaps one other small problem with an auth library in the core, is the obligation to have a set of database tables that would meet the standards and expectations of the author of that core library - at the moment very few CI libraries require any particular tables in the DB - and I think it's a sensible policy to keep that number as small as possible.
[eluser]thody[/eluser]
[quote author="jedd" date="1250113491"]
The fact that several already exist, and most people end up writing their own anyway, kind of answers this question.[/quote]
I respectfully disagree. That fact merely illustrates that there's a need for such a library. The ubiquity of them simply shows that we're not happy with what's out there, or we'd stop trying to reinvent the wheel.
As for the specific needs of each application, obviously those will remain in the domain of the app creator. I'm referring to an abstracted library for core functionality, which is common to any Auth library. The concept is no different from the cart library, which will have additional custom functionality tacked on by developers for needs specific to their application.
I actually didn't say I had created a library, I've just used what's out there (Redux, Freak_Auth, etc). For the most part, I've found them bloated, and in need of abstraction.
Regarding DB tables, I understand your concern, but I can't help but think it's an acceptable trade off if it means simplifying the integration of a very commonly used piece of functionality.
[eluser]jayrulez[/eluser]
[quote author="Thody" date="1250114458"][quote author="jedd" date="1250113491"]
The fact that several already exist, and most people end up writing their own anyway, kind of answers this question.[/quote]
I respectfully disagree. That fact merely illustrates that there's a need for such a library. The ubiquity of them simply shows that we're not happy with what's out there, or we'd stop trying to reinvent the wheel.
As for the specific needs of each application, obviously those will remain in the domain of the app creator. I'm referring to an abstracted library for core functionality, which is common to any Auth library. The concept is no different from the cart library, which will have additional custom functionality tacked on by developers for needs specific to their application.
I actually didn't say I had created a library, I've just used what's out there (Redux, Freak_Auth, etc). For the most part, I've found them bloated, and in need of abstraction.
Regarding DB tables, I understand your concern, but I can't help but think it's an acceptable trade off if it means simplifying the integration of a very commonly used piece of functionality.[/quote]
I support the idea of including an auth library in the core. I don't think 3-5 more KB will make CI bloated and i'm sure a lot of developers would be more comfortable using an auth library provided by CI than from the bunch made available by community members.
[eluser]Pascal Kriete[/eluser]
This isn't about file size. You only load what libraries you need, so even if we add a dozen, it doesn't have any performance implications.
There's more to writing a library like this than just writing a bunch of code. The code for an auth library is quite simple, which is why there are so many of them. It gets a bit more difficult as you move into permissions and making it flexible enough a wide variety of applications (from simple one person login, to a full fledged cms with layered permissions).
However at that point it no longer qualifies as a "simple" library in my book.
The larger portion is that any addition to the core needs to be tested, documented, and subsequently supported. This takes away from resources that could otherwise be used to improve the existing code base.
[eluser]thody[/eluser]
[quote author="Pascal Kriete" date="1250118336"]There's more to writing a library like this than just writing a bunch of code. The code for an auth library is quite simple, which is why there are so many of them. It gets a bit more difficult as you move into permissions and making it flexible enough a wide variety of applications (from simple one person login, to a full fledged cms with layered permissions).
However at that point it no longer qualifies as a "simple" library in my book.[/quote]
I agree, layering in ACL would remove it from the simple library category. Further to that, when it comes to more advanced permissions, we're no longer talking about common functionality, as permission layers are very app specific. What I am proposing is that there be a library to handle core auth functionality (User create/read/update/delete/login/logout), which is the basis of any of these custom implementations.
If the purpose of CI is to provide a rich set of libraries for commonly needed tasks, I think this proposal is well-founded.
[quote author="Pascal Kriete" date="1250118336"]The larger portion is that any addition to the core needs to be tested, documented, and subsequently supported. This takes away from resources that could otherwise be used to improve the existing code base.[/quote]
This is true of any additional code, such as the new Cart library, so I don't really see how it factors in.
[eluser]jedd[/eluser]
[quote author="Thody" date="1250114458"][quote author="jedd" date="1250113491"]
The fact that several already exist, and most people end up writing their own anyway, kind of answers this question.[/quote]
I respectfully disagree. That fact merely illustrates that there's a need for such a library. [/quote]
I believe this is an incorrect conclusion from the facts in evidence.
I think it illustrates that there's a need for several libraries, and that in turn is because no one library can satisfy everyone.
Given there's a half-dozen very good auth libraries out there - I investigated a number of them a few months ago - that are all very well documented (but for the URL, you'd easily think it was an official CI library), with clean API's, extremely well written code, etc - I don't think the answer to this problem is 'let's write another auth library'.
[eluser]jedd[/eluser]
[quote author="Thody" date="1250119959"]
This is true of any additional code, such as the new Cart library, so I don't really see how it factors in.
[/quote]
This, and something you said earlier, suggests that you're under the impression that the CI core contents is democratically decided upon.
The Cart library is presumably there because EL decided they needed one for their own reasons.
Consider that EE uses an authentication system, but it's not published anywhere - this is either because it's so good they don't want to give it away, or it's so convoluted and application-specific that no useful, basic, abstracted system could be extracted from the codebase. (My guess is the second 
[eluser]thody[/eluser]
[quote author="jedd" date="1250120975"][quote author="Thody" date="1250119959"]
This is true of any additional code, such as the new Cart library, so I don't really see how it factors in.
[/quote]
This, and something you said earlier, suggests that you're under the impression that the CI core contents is democratically decided upon.[/quote]
Not at all. But the fact that they're releasing it suggests they have something to gain from doing so, and presumably the better it is, the more likely people are to use it.
[quote author="jedd" date="1250120975"]
The Cart library is presumably there because EL decided they needed one for their own reasons.
[/quote]
Yes, undoubtedly related to the fact that they're working on a Simple Commerce module for EE.
[quote author="jedd" date="1250120975"]Consider that EE uses an authentication system, but it's not published anywhere - this is either because it's so good they don't want to give it away, or it's so convoluted and application-specific that no useful, basic, abstracted system could be extracted from the codebase. (My guess is the second [/quote]
That may be true of EE 1.x, however I suspect that since EE2.0 is CI powered, that may no longer be the case. For all I know there is a new Auth class, and they're intending to release it at some point, which is why I started this convo in the first place. 
[eluser]jedd[/eluser]
[quote author="Thody" date="1250121899"]
That may be true of EE 1.x, however I suspect that since EE2.0 is CI powered, that may no longer be the case. For all I know there is a new Auth class, and they're intending to release it at some point, which is why I started this convo in the first place. [/quote]
Possibly, though I have a vague memory of reading a claim somewhere on the forums that EE 2 runs on something very close to current SVN.
I should have mentioned earlier - I think a generic, abstract, auth class shipped with CI would be a really nice idea, and it's something that a lot of people, familiar with fatter frameworks, point out as a perceived major shortcoming (it'd be nice just to shoosh them up).
It's just that I simply don't think it's possible to have one that's useful to more than a small percentage of people.
|
