Making third party contributions work side by side

[eluser]xwero[/eluser]
I was wondering why every application that has authentication has its own user table. Shouldn't we, as a community decide standard tables with standard fields? For example the users table has the fields id, user_name, password.
If the application needs more user data then a application specific user table is created linking to the standard users field(s).

I hope all third party developers can work together to find the commonalities in their work. This does doesn't have to stop with database schemes, it's just a starting point.

[eluser]garymardell[/eluser]
Are you suggesting it with the prospect of having applications linked in some way. So for example now people want to bridge a forum with a ci application? If this is not the case then i see little reason to unless for some reason you would want to swap the auth library you are using somewhere down the line. What happens if for example one auth library purely wanted to focus on email login and had no use for user_name.

There may be common elements or atleast standards that could be talked about but i don't think a forced db schema is practical in some cases. What other standards do you think should be considered apart from db schema.

[eluser]davidbehler[/eluser]

What happens if for example one auth library purely wanted to focus on email login and had no use for user_name.

If the application needs more user data then a application specific user table is created linking to the standard users field(s).

Guess that answers your question. Whenever an application needs a field that's not in the standard table it creates a new table that linked to the standard one and that holds the additional fields.

I really like that idea and hope that quite some people will work on this!

My proposal for a user table layout looks like this:
Table name: user
Fields:
- user_id PK, INT or BIGINT, auto increment
- user_name VARCHAR(30)
- user_pass VARCHAR(32) (for storing md5 hash of user password, could be extended to VARCHAR(40) for sha1 hash)
- user_salt VARCHAR(32) (for storing md5 hash of salt, , could be extended to VARCHAR(40) for sha1 hash)

I think salting passwords is courteous when saving login data and should be part of the standard.
Additional fields I would like to see are user_email, user_date_last_login and user_is_active but I can see why not everyone would want them in the standard.

Another thing we would have to standardize is naming conventions for tables and columns!

[eluser]garymardell[/eluser]
The idea was more that there will be redundant data. If the community agreed on say a set password hashing + salting method would be good. I think how you store it shouldn't matter. I can't see how this would matter if it was a standard or not.

[eluser]davidbehler[/eluser]
Okay, to avoid redundancy you could always go and not call the fields user_name or user_email but give it a more general name like user_identifier or something. That would allow you to use name, email, some kind of number or god knows what else for login.

The community doesn't have to agree on a hashing method, but having a varchar(32) field for password hash kinda limits the hashing functions you can use, that's why I thought it might be a good idea to actually extend the field to e.g. varchar(40) to allow storage of md5 and sha1 hashs.

[eluser]garymardell[/eluser]
If there is no agreeing on hashing algorithms then what is the point of the standardized db schema. The only benefit i could see was for cross compatibility between systems making for easy bridging. Yet without a standard hashing algorithm this is thrown out the window too.

Also for the password size, what if the user were to use blowfish or some other encryption installed on their system. Some sites may require additional levels of security.

It may sound like i'm arguing this movement but i'm really not. Im just trying to see from the practical side that you cannot standardize one thing and not the other. If your going to decide what information can be stored then you will have to agree on how the information will be generated.

[eluser]davidbehler[/eluser]
I guess I wasn't thinking far enough! You are right, it definetly makes sense to standardize hashing, salting and all that. That way a user can switch libraries without having to update all the passwords and so on.

If someone wants higher security than the standard he just has to use a library that provides that using fields in an additional table.

[eluser]xwero[/eluser]
The end goal would be to be able to drop in blog A or B next to forum C or D that are based on the community standard. If the community wants to go for a common authentication library or for a replacement of one of CI's libraries it's all fine by me.

Standardisation means there will have to be made some compromises, it's the idea to support as much components that are willing to follow the community standard. It's useless to support third party code that takes another road. So i hope people who already have developed components want to discuss on how their components can work together and more important share parts. But of course everyone else is invited too.

If CI is the skeleton the components are the organs. Maybe there shouldn't be one standard but a few standards like there are bonemarrow matches where a 100% match gives you the most assurance but a 95% match can work too.

I guess this thread is an antenna that receives the willingness for standardisation within the community. Maybe proposals here should be seen as see before you buy samples, they don't need to be discussed in depth already.

[eluser]garymardell[/eluser]
Well to push this forward abit more, i guess a logical step would be to take the most popular auth libs now such as redux, dx auth... and make a table and fill it in with the fields they use for username, password, email, salt, and the field lengths and then record the hashing method into another field. Ie. md5(Password.Salt). You don't have to use the code just the order and method is important.

Okay, i set up a wiki page with a table. Anyone can add their own auth lib or someone elses in as a column. It will help to get an idea of what the current trends are.

http://trackvn.com/doku.php/auth:index

[eluser]xwero[/eluser]
thank you for the first step to let different contributions work together