Redux Authentication 1.4a (24th July 2008)

[eluser]sikkle[/eluser]
Scheneshift :

Session type goes directly with the kind of project you handle. Majority of commercial apps need ACL, so you already have your SQL access. I say let Mysql do whatever it's good to do. The Query optimisation could change by project, because at some point you can remove some security layer to prevent that, but at which price ?

For most standard real world application, one sql is nothing, if your system get up to MANY and i say MANY connection, you prolly want to think about what is the best for scability, filesystem isnt always the best realy, so database will be a better choice again.

So, what range of security do you need ? this is the question, when i build basic website with small backend, i don't care much, when i build major client application i'll go with the SQL biiiiig time.

Good luck.

popcorned ; good to see you active and take time for your libs, good work !

see ya around guys

[eluser]Sceneshift[/eluser]
Thanks for the post sikkle. I'm probably the worst developer ever because I always code in the most minimal way ever, one of my controllers has 16 queries and it seems like the end of the world to me, but from reading your post I am starting to think I'm worrying needlessly. If it ever became a problem, I could always just upgrade the platform!

popcorn: If I was to implement the session database method, would there be any changes to the library or is it a literal replacement of the CI session class?

[eluser]Popcorn[/eluser]
You put the file into the "application/libraries" folder, then autoload it. Everything else is taken care of.

[eluser]Popcorn[/eluser]
Redux Authentication Version 1.3 (04/05/2008)
* Optimization : Last Insert ID used in registration.
* Misc : Secret answer now hashed.
* Misc : Get group didn't use the correct parameter.
* Misc : Check access now in the login method.

Site updated

[eluser]Sceneshift[/eluser]
Missed a ";" on line 41 popcorn

Also, your controller still uses "get_username" which appears to have been changed to check_username

[eluser]Popcorn[/eluser]
Oops, updated. Thank You

About the get_username, I plan of moving those type of things to a helper which I think is more appropriate. I'll update my examples.

[eluser]Sceneshift[/eluser]
Popcorn,

Was there any particular reason why you removed the function which returned all the data on a user in one query? I found that pretty for useful for checking the users credentials and whether they were activated or not in one go.

[eluser]Popcorn[/eluser]
It didn't return ALL the user data. I moved this into the login method for a couple of reasons :

1 : Cut down on SQL statements, instead of making 2 select statements, we now only use 1 statement to find out if they're banned, not activated or have the wrong password.

2 : Why would you let your users login, then check to see if they're banned. Why not just check to see if they're banned when they login instead. Couldn't find a negative to this personally.

The login function returns flash data notifications if you ever need to display this information to the user.

[eluser]Popcorn[/eluser]
Sorry, it's not "redux", it's "redux_auth" for the config autoload.

Kind Regards,
-Mathew

[eluser]MCrittenden[/eluser]
In autoload.php, change the autoloaded redux library from "redux" to "redux_auth". I'm not sure why the instructions just say to use "redux".