However, without a dynamic link to the user table, these will be searchable by all and sundry.
Oh, they are not supposed to be searched by non-subscribers. I had forgotten about that.
Hrm. In that case, export the user table daily from MySQL to an .htaccess file or something like that, and copy it to wherever the old threads will be.
Sorry if all of this seems far-fetched or too Unix-specific. I'm at work and procastinating (thinking about anything work-related except work itself).
.htaccess uses the standard Unix crypt function to encrypt its passwords. But anyway, it was just an example of how things could be done wrt limiting access to the archives.
.htaccess uses the standard Unix crypt function to encrypt its passwords.
Is that MD5? Because that's how ours are stored.
Nope, they are different functions. And in that case, I'm afraid that this option isn't feasible, with MD5 being one-way and all that...
Let me check if there's any way to make .htaccess use MD5 passwords, though...
Edit: oh wait, there *is*. .htaccess uses by default crypt() passwords, but you can configure it to use MD5 too.
Anyway, these are all implementation details, and I'm sure something can be worked out in the end. The first decision to make, if I understand correctly, is still at a higher level...
How would the user table stay updated? Every time a new closed thread was ported, an update to the archives user table would be required.
Well, yeah. Basically. That would be how.
Update it when the archive is updated.
Edit: probably by using the most-up-to-date version at the time of archiving.
I'm in voting mode:
I say option 1. It is what I'm used to so it might just be a familiarity thing.
Update it when the archive is updated.
But the 100 users that joined between archives can't hit the site.
I still vote #1.
But the 100 users that joined between archives can't hit the site
Could also sync it twice a week, whatever makes it smoother.