Hey a&w,
cheers for the suggestions, and spelling supervision: given that I’m not an English native speaker, I need it!

Well about your requests, let’s start (more can be found on the usergiude: Session Class):

FAL sends just 1 cookie to the user, containing the unique session ID identification number (the same stored in the ci_sessions -> session_id table). If I’m not wrong this cookie expires after 2 hours of user inactivity (this is controlled by the the variable $config[‘sess_expiration’]    = 7200;).

Well the DB table autoinstallation is planned for next release!
Stay tuned!

Dan

Thanks for the great work on 1.0.4.

I have installed 1.0.4 with a clean install of CI 1.5.3 and I am doing some testing.

Has anyone noticed a performance hit after installing Freakauth_light?

I just have the welcome controller and view. 

I DID NOT add any user checking (ie $this->freakauth_light->check(‘admin’) )

In the autoload.php file, Freakauth_light is autoloaded

When I load / refresh the welcome page, my “page rendered in” stats show between .1 and 2.4 seconds.

But if I remove Freakauth_light from being autoloaded

The “page rendered in” stats show mostly between .04 and .29 seconds (most of the time, it is under .1 seconds)

Quite a major difference.  Is anyone else seeing this?

That would make sense to me. In Sentinel I didn’t autoload the library it was loaded through the controller on a per/need basis.

Also for those that are curious - I am rewriting the Sentinel library to be smaller, more efficient, and more abstract (no views or controller dependencies). When I get something worth sharing I will share it as its own thread (since the code base isn’t derived from F.A.L anymore).

smalljohnson - 17 May 2007 02:36 PM

...
When I load / refresh the welcome page, my “page rendered in” stats show between .1 and 2.4 seconds.

But if I remove Freakauth_light from being autoloaded

$autoload['libraries'] = array('database');

The “page rendered in” stats show mostly between .04 and .29 seconds (most of the time, it is under .1 seconds)

Quite a major difference.  Is anyone else seeing this?

I was going to inquire along the same lines.  Have a look at my thread here.  I’m wondering what the performance comparisons are between the options I stated.  When you do an autoload of a configuration, CI actually loads the file twice.  I’m thinking autoload should almost just be for config files that do not have a corresponding library (because if there is a config file with a corresponding library it will be loaded anyway).

To take advantage of the configuration that CI finds without autoloading the controller’s constructor would just need to be prepped a little different (see the thread).  Maybe do a performance comparison between these methods and report your results?  This would be a standard situation for how to handle autoload of config files, not just within FAL (maybe?).

I generally just use autoload for db_session, database and very heavily used helpers…

Question to the FAL team

Is there some change in the dbsession lib file since FAL 1.0.2?

As I alraidy use this dbsession lib in the reste of my application and that I have taken it into your FAL 1.0.2 distribution. I would like to know if you have made some change in it?

Thanks

Dan,

I think you found another anomly there; I was talking about the fal_front register() function and validation error handling for registration. Test: See what happens if you simply go to /auth/register in the sample views and submit the form with all the fields blank. I do not get a return on the user_name_error string. All other error strings are returned. I have looked through the code and tried to figure out why this is, but I am sorry to say that I have not figured it out, yet.

As for the custom and required fields, I tend to disagree with the approach. Values are either required or optional. If there are required values for an account, they need to be submitted with the initial creation of the account, at registration. To load a seperate form, or whatever, to assign more required values after username and password have been submitted makes no sense. If you truly require those values in the first place, how are you ever going to get them? By crippling the account until they are entered? Surely it is better then to require them in the first place as a condition to register. A user profile with entirely optional values is another matter. (How many people have filled out every field in the EE profile for this forum?) It is thus not a question of simple or advanced registration. It is a question of handling required or optional values.

thierryREY - 18 May 2007 05:23 AM

Question to the FAL team

Is there some change in the dbsession lib file since FAL 1.0.2?

As I alraidy use this dbsession lib in the reste of my application and that I have taken it into your FAL 1.0.2 distribution. I would like to know if you have made some change in it?

Thanks

No don’t warry!
Given that db_session is a third party library, we never touched it since the first release!

Dan

@smalljohnson
You might be right:in fact the Freak_auth.php library can just be loaded in the auth (or whatever you renamed it) controller
Nevertheless I didn’t notice souch a performance difference.
How did you run the test?
Did you use any script/custom software?

@Crimp
About username validation in auth/register
I tried but I got the right message leaving all fields blank “The User Name field is required.”

about custom fields for registration
You right, the functionality to add some compulsory custom fields right in the first registration without much hacks would be nice.
I’ll try to implement it for next releases, leaving the option in the config to go for a simple registration or for a more detailed one.

Thanks for doing that test, Dan. At least I know I am alone