Trouble is it also gives the possibility of just one rogue user uploading their version to a website with their ID for general download.

Snover has ideas on making the unlock procedure web based so that you can do it instantly without the email trun round lag.

Glidos wrote:

Snover has ideas on making the unlock procedure web based so that you can do it instantly without the email trun round lag.

Thanks, Paul. Due to the way I'm using my computer like a "test station", I seem to trigger the ID thing a lot.

I'd get it done before the end of the weekend but Paul still hasn't sent me the information to generate codes. Maybe this thread will put a fire under him, eh? 😀

Did I not? Ooops!

Still don't have 'em, Paul. (heh)

Snover wrote:

Still don't have 'em, Paul. (heh)

I have some stuff for you now. Where would you like it? Shall I send to one of the two email addresses I have for you (it's about 2MB)?

If it's to be done via a SSL web page how about the following...

When a user is asked to register, they pay for their key and they are ALSO asked to specify a unique password...

In this way, if they have to re-install their PC and thus re-install GLiDOS, all they have to do is go back to the GLiDOS homepage and to ANOTHER secure login (for re-registering after key loss) then they type in the password they chose and BAM!

The GLiDOS re-registration server will allow them to get a new key without having to pay-up all over again!

Seems like a good idea huh?

Let's just say that if it WAS done this way, I'd DEFINATELY buy GLiDOS 'right NOW'!

Penny for a thought people...keep the thread going!

Paul.

Could work...Would have to monitor the IP's that use that pass once a month tho to verify that TONS of IP's aren't using a specific pass....

Don't really need that much security because of the security already in the system, but it'll be something like that. Can't remember what we eventually settled on. I'll have to reread my and Snover's emails.

That was basically what we were going to do, although it was not a by-IP thing... it was a you have X number of times to get a new code, and at that point you need to send an email to Paul to get it reset.

The main security was that you could get the code sent only to your PayPal email address. Changing email address would be an admin task that I would perform.

What I can't remember is how we stop one person triggering anothers unlock requests and wasting them. I guess an autogenerated password needs to be sent to the email address as a start to the procedure.

in email:
"please click the below link to retrieve your new code.

note: this link will be invalid in 5 days."

Now if only I knew enough about SQL to figure out how to delete stuff from it in 5 days like that.

Snover wrote:

in email: "please click the below link to retrieve your new code. […]
Show full quote

in email:
"please click the below link to retrieve your new code.

note: this link will be invalid in 5 days."

Now if only I knew enough about SQL to figure out how to delete stuff from it in 5 days like that.

Great idea.

The link doesn't have to be invalidated on the fifth day. It can wait until either someone tries to access it after the fifth day, or someone provides another ID, in which case the PHP script can determine the invalidity.

The link would need to have a magic number in that couldn't be guessed.

Probably the best way to do it is increment the persons unlock count only when they click the link rather than when they register an unlock request.

The more I think about it, the more I like this idea of yours. No need for passwords with this approach, either.

Yeah, I'd probably just do an MD5 of microtime and put that in the SQL database along with the date of request. When (if) the user tries to click on it, and it's more than 5 days old, they get an invalid request. Sounding good. I'll get to work on it now that I finally have your stuff. 😀

Sounding very good.