I've studied up, and I know how to do the sessions and the authentication now. A decision has to be made as to "how secure" we need it to be in regard to sessions. Up to a certain point, there's a trade-off between security and convenience.

However, the next big move is to start taking apart the procedural code, and moving it into an object-oriented framework.

I finally finished moving all of the old Hotrodders "Hot Rod Search Engine" links into our new Knowledge Base (nearly 2,000 links), so that's a big monkey off my back.

Getting there, but slowly.

Wish I could say I know how, because I really need to know.

The biggest need I see for security is when a journal is altered. That's really the only time the server needs to confirm the identity of the client, to make sure that only the owner of a journal can alter it. It should not be too inconvenient to require username and password before beginning an editing session. This could be a place to require https, even.



I really can't help with that.



I'm studying sessions and user authentication again. Can't promise any results.

1. Verify user.
Login, set cookies, start session.

2. Re-verify user credentials for subsequent pages.
Test cookies, test sessionid.

3. End session.
Clear session variables.

Does that look right?

[Edited to add:]



I see bbpassword, bbuserid, bblastvisit, sessionhash cookies. Which one(s) do I need to read? What do I compare it to?

Progress on version 0.43 so far:

-- Changed variable names everywhere in order to have some more consistency: all of the global variables named in _vars.php now begin with an underscore. (That was a mess). Rationale: PHP's globals begin with an underscore, like _SESSION, _COOKIE, _GET, _POST. Establishing a convention like this could be helpful with maintaining or extending the code later.

-- Created a journal_users table as Jon suggested ages ago. For PostgreSQL, this also involved creating a view and several rules so that everything works the same when MySQL's "mediumint(8) unsigned zerofill" stuff is used. In PostgreSQL, the table is:

Passwords are not stored on the server, only a salted hash of the password that the user submits.

-- Renamed some columns in tables to avoid confusion:
In journal_entries, "date" => "entry_date", "text" => "entry_text". In journal_photos, "type" => "i_type".

-- Added some database variables to _vars.php because the above changes in the database tables created a really aggravating, tedious search and replace. Variables added:


-- Cleaned up some ugly messes in _common.php, show_all.php, show_journal.php, show_toc.php and their associated display files.

-- Created a session_destroy.php and a session_test.php to begin trying to understand sessions.

It's still not ready to tar up and post.

Some links to articles regarding SQL injection:

http://www-128.ibm.com/developerwor...ry/l-calls.html

http://www.unixwiz.net/techtips/sql-injection.html

http://www.securiteam.com/securityr...5DP0N1P76E.html

http://www.askbee.net/articles/php/..._injection.html

The trick, now, is to make certain we're not vulnerable to such attacks.

I'm really stuck. For some reason, this thing is mixing session data from different sessions and different users, even after going through session_destroy() and individually unsetting all session variables and cookies. Just what in the world is session_destroy() good for if it doesn't, in fact, do what the manual says, "destroys all of the data associated with the current session."?

The attached tar.gz and zip show the condition of the mess so far.

WARNING: This is BROKEN and should NOT be used on any computer with a network connection! IT IS NOT SAFE AT ALL!

Attached Files

	journals_test-0.43.zip (63.7 KB, 0 views)
	journals_test-0.43.tar.gz (34.0 KB, 1 views)