December 7th, 2013, 01:33 PM
For "derplumo", please:
Could you please post the table structures related to the forgot password mechanism?
Seems like there are calls to "responses" and "sent emails" but its not clear what table structures must exist to make things work.
Thanks for posting the PHP code to the other thread I started recently. I think I'm "almost" there to make it work as you've evolved the various scripts.
December 7th, 2013, 02:53 PM
if there's anything I can help with, just leave a shout
CREATE TABLE responses (
reset_key CHAR(32) PRIMARY KEY,
user INT NOT NULL,
secret CHAR(60) NOT NULL,
request_timestamp DATETIME NOT NULL,
request_ip VARCHAR(39) NOT NULL,
used BOOLEAN DEFAULT 0 NOT NULL,
active BOOLEAN DEFAULT 1 NOT NULL
CREATE TABLE sent_emails (
email_address CHAR(64) NOT NULL,
timestamp DATETIME NOT NULL
Last edited by derplumo; December 7th, 2013 at 02:54 PM.
December 7th, 2013, 03:47 PM
December 7th, 2013, 04:31 PM
I'm seeing data created and sent from the "forgot_password" routines; however, the reset key and token contain characters not normally a part of an English text/data stream and if I capture the full link and paste into a browser to try to reset the password, the result is ALWAYS a failure.
Originally Posted by derplumo
Is there something in the hashing or PHPMailer or (who-knows!) ?? that needs to be configured?
December 7th, 2013, 04:57 PM
oh yea, that was the little bug, it is something in the links in the form (I think it was in the form) wait a minute.
December 7th, 2013, 06:57 PM
ok it took a little longer than a minute, but it was a new bug. in forgot_password.php change $user_id['user_id'] in $user_id around line 77. You can change some double declarations if you want, I still have to make a final version of it because there is also a problem with the activation etc. (if you use it, you can now still use it again, this needs to be changed)...
Thanks for noticing the problem
December 8th, 2013, 06:48 AM
I've really become interested in using the core functionality of this thread in a real-life application. I anticipate being extremely frugal and selective in the matter of allowing people to register and gain access to information that is proprietary or protected by law.
Does it make sense to expand the register.php to require enough information that I can actually verify on a case-by-case basis WHO I want to have access and what their permission level should be, but archive/remove the most sensitive elements to provide as much long-term privacy protection as practical?
My thought is to make the register.php write to a completely independent database, have the procedure notify me by email that someone has applied for registration and then accept/reject them.
If I decide to accept the person, I'll move the essential credentials from the registration DB to the "working" DB and archive all but the essential data (username, email, date registered), probably using an off-line spreadsheet or XAMPP DB to archive the entire original submission.
It may be "overkill" to use a separate DB vs. special table in the primary DB. I'd love to know what "best practices" are on these types of matters.
My expected user population will be quite small and niche interest area (related to music, both sacred and secular). I will use personal evaluation of registrations and employ the open source "secure image" captcha mechanism.
TIA for suggestions.
December 8th, 2013, 06:55 AM
I don't really know where you are working to but I have to say a captcha is always good, some people just want to see your server burn... I'll try to include it in the next version of the password forgot system
I know a little bit of security but this is Jacques territory
December 8th, 2013, 07:01 AM
Do you mean geographically "where"?
Originally Posted by derplumo
December 8th, 2013, 09:05 AM
no the 'what' What kind of website you're working on, wait, I'll send a pm, otherwise this thread will become bigger and bigger...
January 6th, 2014, 05:27 AM
hello guys, first post, firstly great site and a wonderful piece of code here.
However, this line in common.php freezes the whole script for me:
If I remove it, login.php at least works, but register.php still does not. I am a relative beginner, does anyone have any ideas what's happening?
January 6th, 2014, 07:21 AM
What's your PHP version? This sounds like a really, really old bug in PHP 5.2.
Either way, this isn't a simple application problem. It means there's something wrong with your PHP.
January 6th, 2014, 08:23 AM
Thanks a lot for the quick response.
Originally Posted by Jacques1
Sadly, I'm running PHP 5.1.6 (and mySQL 5.0.95.)
So I assume this bug also affects versions older than 5.2.
I'll see if we can upgrade. Thanks again.
January 6th, 2014, 08:29 AM
You definitely need to do that. The 5.1 branch has been abandoned a long, long time ago (in 2006, to be exact). It's full of bugs and security vulnerabilities waiting to be exploited.
Originally Posted by Dusk1983
The current branch is PHP 5.5.
January 6th, 2014, 08:53 AM
OK. Sorry to take this off topic but are the mySQL_* functions at least supported in 5.5? I know they're deprecated, but our site remains full of them... not good! Thanks.