Using Email Address to Login

Hi Everybody, this is Lan in the Philippines!

I have noticed that a lot of logins these days are asking for just your email address and using it for a login.  Email address plus Password gets you in.

I love the Access_user class, but was requested to make a system which logs in with the email address and password....

So for a few days I have been looking at how the access_user_class.php could be slightly modified to accomplish this!

I now have a working system, based on version 1.93 in which I can change just a few settings in the db_config and switch from using login based to email address based access_user.

In fact, it works so good that you can even delete the login column all together!  That could be a big plus for sites with a lot of users.  (I'm doing one for a christian men org that had millions of members world wide.)

I will soon plug the changes into 1.94 and if anyone is intrested, I would be willing to share it (but I don't have a huge amount of bandwidth!

Thanks, Lan

Lan, you read my mind. 

I started looking at using an email address as the login id tonight.  Hadn't gotten very far yet as I was still trying to think about how it would work.  I would love to see your changes, what is the best way to contact you.

Thanks

Eric

Hi Lan,

I suggest that your mofications are inside a class extension? (check the file ext_user_profile.php)?

otherwise I can't see how it is possible to contribute your version here...

Hi Eric,

I never publish my email address on the Internet... but you can give me a first shout at a form on:
http://email.7t.net/

That will give me your email address and when I reply you will have mine (careful typing!)

I have the class working fully with all examples on ver. 1.93 - time permitting I will have it completed in 1.94 and maybe Olaf will want to add this feature to the class...

-Lan

Hi Olaf,

Well, the draw back is that the these are not really extensions, but modifications!

I am not really proposing anything... they meet my need and that is why I am doing it... However, in the spirit of "give something back" - I am willing to send you the modified file and then you can test it and see if you would or would not like to add it to the class!

If you don't, I've lost nothing and maybe Eric will benefit a little.

If you add them, then when a new update comes out I won't have to modify it all the time!  And any body who wants to login using an email address can do so with just one little changes in the db_config file!  (and a mod to the user Table or loading a very slightly different seed sql file with no login column!).

Anyway, I have the modified class fully working in 1.93 - I just got 1.94 and when I finish, if you want the modified class, you can have it!

-Lan

PS: I'm not asking for anything.  Just offering what I think is a good idea built on a great class!  :)

I like the feature to login with an email address, but I think it's hard to do in this class if you want to change the e-mail address. (you should test this)

Thats is why I used a login name (there is no way to change them and it is also the database key, try to index emailaddresses in a 100.000 record table), look big forums are using a a login name too and not the e-mail address.

Don't send me your source code, I don't have the time to check that ;)

My next (very important) step is to intgrate better e-mail functions.

lan, olaf

Well I was thinking that when a user registers, instead of having a user create
create a login id themselves, the class could generate a guid for the login id and store it in
the db.  In other words, create a loginID not tied to any data a user enters upon registration. That way a user could change all of their data (email address, password, etc.) but the data
is associated with a loginId via a guid. 

Just thinking out loud here, not sure of the implications.

yes this way to have a key, but anyway this question is the first time since 60.000 downloads, I think there are other improvements first...

I did test this - I tested every page in the example and it works perfectly!


Actually you are using an index key in your access_user_class already (Unique) for email.

I'll grant you that email addresses tend to be larger than login names - however if you are going to use an index key on both (like access_user does) then the point is not as valid.

I shy away from "that's the way the big guys do it..." It ranks up there with, "that's the way we always done it so that's the way we will always do it..." thinking in my book!

Consider that "big forums are using a a login name" may not be so much to do with what is best at this time.  They are usually big because they have been around a long time!  I don't want to argue the point forever, but consider if access_user was written in PHP2!

Likewise, even if the big forum programmers wanted to change, consideration must be given for the thousands of current users!  To change my just not be a good idea in that the users must all be retrained!


OK - Fair enough - I'll put it on a site with explainations and let you and others test the mods.  Anyone who likes it and is able to follow the concept will have no problem making the mods, they are really simple...

Hey, I really appreciate what you have created!  I look forward to seeing future imporvements!

To a certain extent Olaf has already done this in access_user in that the table user Column ID is the Primary and Unique index key.  It is, sort of, a login that nobody (but the program) can use!  If it wasn't for this I couldn't have made "access_email" work so perfectly!

I will have this up on my test site soon and will post the URL so you can see what I mean!

ok its OK (open a new thread for this), and don't forget to support the people ;)

yes nice I have one two with html templates etc. anyway its nice that you try to make this class better, but don't forget your a just one user!

It's impossible to the other users to present them a totally new version. I have a second version too, but its a to complex update to merge this with the current version.

Classes need to be used unchanged and if a user needs more functions he has to extend them.

Wow!

Olaf ... I could not AGREE WITH YOU more!

Using these Eight Tiny, easy and well tested modifications, that would allow anyone to choose between setting up access_user with either email/password or login/password, I have had perfect success!


Because of what Olaf said above, I hope Olaf will consider including this tiny, easy, and well tested modification into the access_user_class so everyone can enjoy them!

If anyone would like to see how I did it, the Complete Documentation is at:

http://7t.net/classes/

On the other hand, we have to accept that this is Olaf's access_user class. If Olaf changed his mind and now doesn't want to add the easy and well tested feature, to login with an email address, into his class, that is Olaf's choice!

Anyway, I give it to Olaf free, easy, and fully tested!   :)


If Olaf does not want to add this easy and tested feature to access_user, can anyone look at the mods and give me an idea how to put these into an class extension?


-LAN

PS: Enjoy life!

Lan, just wanted to say you modifications work great.  thanks.

the bad thing is that you need to change the class again with the next update ;)

Yep, I know, but thats why the modifications Lan did should be incorporated into the class itself.  ;D It gives the class flexibility to handle both situations (login with email or login with login account)

Once again, add this to the enhancement list, hopefully not at the bottom like my other suggestion.  ;)

look this mod is not good for the main class, if Lan writes a extenstion I will include it...(myabe this is needed for the unvalidated registration too ;0)

Hey Everybody, it is Olaf's class.  He has the right to take it in any direction he wants and to accept or reject any idea he wants!  Lets not fight about it.  The mods work on Version 1.94 - it is a nice point to look at... Maybe some will benefit by learning how I did it!  In fact the mods work so well that I am using them on a live site here in the Philippines!  But I am the one who is going to maintain that site, not Olaf!

I did some work on an ext_class to do this... just before 6 of 7 main under water fiber optic connections to most of asia were cut by an earthquake!  Today the Internet is actually "usable" at 15Kbps!  Talk about slow! (where is my 1.5Mb!).

Anyway, to the 100 plus people who asked me to just make an email only branch - I will consider that.  I actually have some other ideas too that would not fit well in Access_user - but I suspect that would take a complete or major rewrite to do... (like adding first, middle and last names and date of birth in the class for ID reasons!). But doing a new class is an idea that actually Olaf first suggested!

But hey, let's give credit where credit is do.  Olaf created this class, Olaf maintains this class, Olaf is the one who decides what should or shouldn't go into this class.  I understand that Olaf is working on a class mod that will use the login to create individual directorys.  I am not sure why or what that has to do with access_user (it seems to me to belong in the profile_ext, to be used if wanted, or some other class) but that is my opinion.  That is the great thing about this - we don't have to agree!  But when it comes to access_user_class - the only opinion that matters is Olaf's!

The point is, it ain't my class, it is Olaf's!  I may think that most people won't want to make a bunch of directories out of the login names (in fact, I couldn't even give my wife a hard reason why someone would want to do that!) But it is not my class, it is Oalf's, and I will defend Olaf's right to do with it what he wants.  When and how he wants!

Olaf's direction may need storage space for his users!  Great!  My work is more database driven, people oriented websites.  For example, one change I plan for my sites is to use the "real_name" and for a nick_name storage and add first_name, middle_name and last_name and date_of_birth in the user profile.  If I write a new class for email access, I will include these in the basic class!

Since my site has a semi-static layout, the top bar being the same, the nav bar dynamicly changes based on the access_level, the main frame likewise dynamicly changes based on the access_level and the page_number, I used the PHP switch command and include statements, and put this all inside of an index page that changed even the title bar!  But ALL this is way outside of the Access_user class.  In fact, although I use email_address for access, you could do the very same thing with the access_user_class as Olaf designed it (just use the login and pasword).

So maybe I'll do an extention or even a new class that deals with unvalidated registration and dormate accounts to reduce the storage space (I'm working on a database for 6-10 million users so even small data like the login can used up a lot of space! Dormate accounts and unvalidated registrations, complete with mailing addresses, could use up hundreds of MB or even gigs!).

So anyway let's thank Olaf for his GREAT! class and see if we can do the mods in a few versions to come, or just add them to an extention!

Thanks Olaf!

-Lan

Lan, its not for hosting people files... think about a domain registration site, all contracts/bills are stored this directory... Go farther what about to us this class to maintain users in a linux environment...

...and of course I published this class as open source because I like to know what people think about. Every suggestion is welcome, but for all other users I need to think about a lot (the last suggestion I followed to quick has the result of three updates to solve the related problems)

Yeah, I could see that, but I think most just use the paid in advance / database route.  Yes the data base could be changed or corrupted (so could the directory) which is why we have back-ups!  But it is an idea...  For someone...


This one I did think about after my last post.  I use FreeBSD on all my local servers (13 years now!) and local users do have a directory.  I can't see me using it to solve a "non-problem" of mine, but I am not so bold as to say my solution is the only one!

Directories still seem like a profile or extention class to me.  The Login field is already there in MySQL and so any scripting to use it for making directories could be easy in your php script or class extention.

OR

Directories could easily be turned off in the class if "email" was chosen in the config file.  (Turned on for login!)  Meaning the directories option was not available in the email / password option.  If you need directories, you need a login.

BTW I still use the login column in one test bed... by changing even fewer things! :) I use it for a name.  User_name (for login/password) or Nick_name for greetings (email/password)!  I did rename it from login to name to remind me it has a dual use!  (Not advisable to most! - this is really advansed stuff if you are a newbie reading this!)


Yeah, I saw the thread on that!  :(  I don't uses the cookie login as I don't like the security.

I did test my mods with every page you published in the downloads to be sure they really worked flawlessly.

Hey, I am greatful, the 1.94 class, as modified, with auto login disabled, works for me!  I plan to track the Access_user_class future versions, and make my mods, for a number of future public service sites here in the Philippines, as long as it is just a simple as this!

When the Philippines gets some bandwidth back, I will give a shot at making an Access_email_ext as well as a layered site template for fun.  But for me... it actually seems silly (for my use) when the 7-8 mods are as easy and solid as they are.

Thanks again Olaf - I really love this class!  It has benefited me, and Filipino people a lot!

-Lan

as I said before I have this already working but need to integrate this features into the Open source version, so give me some more time...

I finished an Access_Email_Ext, but it is not practical.  Although possible, it must rewrite so much of the Access_user_class that it would be more practical to just make the eiight tiny little changes by hand each time there is a new version.  In effect to create a new class with each new version...  The Ext rewrites about half the class and about 7 major functions, where the eight little mods are just eight tiny little mods!  :)

For the record I will not be releasing an Access_Email_Ext.

:) never said it will be easy...