Status so far of the SQL work...

[wolfwings]

Okay... so far I have the following coded for the website back-end as SQL functions, including test-case SQL scripts when appropriate:

• Infrastructure functions.
  • Password 'salt' generator that's deterministic inside of a 24-48 hour window for a give login name.
  • SHA1-based HMAC 'salted password' hasher.
  • SessionID-to-UserID dereferencer.
• Validation-code handling.
  • Request a new validation code for an account.
  • Test if an account is valid once a validation code has been applied.
• Password handling.
  • Password checker accepts tests with either a plaintext (to handle javascript-disabled browsers) or properly HMACed passwords transparently.

Stuff I still need to finish as SQL functions:

• Password handling.
  • Set a new password when given the old one.
    Will rely on the PHP code to handle/catch non-HMACed passwords from javascript-disabled browsers, unlike the password-checker.
• Account management.
  • Create a new account.
    Will create an account with validation set to false, and immediately kick back the validation code for the user so PHP can e-mail it off.
  • Create a new SessionID for an account/password pair.
    Relies on password checker function.

Once that's all done, coding up the actual website will be relatively minor by comparison for the core structure, but that's the intent. Keep the PHP code unobtrusive for main page-content, allow easy styling of the website itself and integrating with other tools like forums and what-not.

I already have the core website-infrastructure code done on the PHP side. Mostly it should be sitting down with a couple nice artists I know that are going to be working with me on the website, and kit-bashing things together so we can show a few ideas to the rest of the convention staff; then fully flesh out whatever folks decide looks best.

And when this is all said and done? I'll be packaging up the raw scripts and minimal website code with all styling stripped out, and punt it up as an archive for others to use. I'm tired of hearing about folks struggling with making a website for their convention/get-together/whatever, and why have a dozen other folks re-invent the wheel? That, and I figure I'm using best-practices as I understand them, so I'd like to give others a chance to look over the code and hopefully warn me if I'm doing something that's causing a larger hole than it's covering up.

Comments

[uplinktruck.livejournal.com]

*blinks, stops head from spinning...*

Okay, I spoke with Shanya about this. I'm loking at a Wiki to be fed content by TV Trolls myself and read by the general public. Can any of this do that?

Well...

[wolfwings.livejournal.com]

...plain MediaWiki can likely do all that, including playing video in the wiki. Just prevent editing by unauthorized/new users, in effect blocking all but 'editors' from modifying articles, as one possibility?

This is specifically being built to track membership levels and to provide a sort of 'central user directory' that other sub-sections like off-the-shelf forums or MediaWiki or even the LiveJournal software-suite (not the site, the actual server-software if installed on the same server as a possible alternative to standard forums) can authenticate against.

It won't directly handle payment or postings or news, it's JUST a centralized user-tracking system with e-mail verification using best-practice password-hashing so it's as secure as possible over a non-HTTPS connection vis-a-vis password sniffing. =^.^=

Re: Well...

[uplinktruck.livejournal.com]

I'm not looking for payment. Just a source for technical TV data and history that is accurate and anyone can read.

There are a lot of know it alls out there that no nothing of television and will tell you all about it. That's why the editorial oversight.

We should chat over the phone sometime. I have to go catch a storm.

Re: Well...

[wolfwings.livejournal.com]

(310)735-7838, also posted on my website.