Super minor release.
Included the logon logger.
Included the ability to view your password during registration. Submitted by John Bovey. Will probably add this to the user account password changer. Maybe manual user creation too.
The cron stuff is in the new sql dump...but so is the stripe stuff. I'll pull that out. I'll reset all the auto increments and all that kind of stuff before we do that final build.
Ouuu I like this!
I wanted to add an auto-generate to the manual creation but I haven't gone it yet..........thoughts?
We're making a lot of progress with this 4.3 update!
I have a minor update to admin.php to push so I'm kind of waiting for @karsen to see what he is pushing in his branch and make my final updates (basically anything he doesn't do that I wanted to do)
Looking forward to it
Btw you have Google login enabled in the SQL by default...
For my own reference:
There is an issue with the logger in the message functions, it is logged the $fname in the log as the person sending the message.
Sorry, was out of town for a couple days. I haven't made any branch changes so go ahead and do anything you need to.
@Brandin. Are you talking about auto generate passwords?
What I tend to do is to do a token generate then bcrypt that then bycrypt the bcrypt so it's essentially an unknowable password (since bcrypt is not a deterministic hash the results of the same token are different). Then I force the user to go through the password reset to get their own password. If you're talking about autogenerating a password that we send them, my thought would be to bcrypt something to get pseudorandom noise and then give them characters 8-19 as their password to give them a pseudorandom unpredictable password that we can share.
Does that make sense?
1. Generate a random token.
2. Bcrypt it (don't store it)
3. Shorten the string to only characters 8-19 (since characters 1-7 are always $2y$12$
4. Bcrypt that 12 character string as their password store that to the database and then you can send them the password.
The problem is that doing it that way, the pw would be in plain text in email, so they should still reset the pw, which brings you back to creating a password that even you don't know.
I think I have a few things I want to add to the todo list that I'm going to try to tackle. I think the basic menus should be moved to the db which would make them a little easier for people to modify. Right now they're kind of a mess as shown by that guy who couldn't figure them out.
I also think recaptcha should be in the db.
I also want warnings about default passwords and recaptcha to go to the admin panel.
I've also worked out a way to do database "migrations" where people can skip steps in upgrades and say update 10 point releases all at once and it just runs the migrations in order.
We're super close, but I think this will be good. Thoughts?
Btw, with the migrations, people could essentially update their userspice with git and just constantly pull in the latest code, run migrations and be done.
Actually, every time I think about doing the db in the db, it looks like it's just going to thrash the db on every single page load. I'm going to look at some usersc options.
