Again I’m faced with another task that is a result of our sort of random, ambiguous office policy.
A couple of years ago I created a web app that collected award nominations. Basically people could create accounts, log in, nominate someone, then come back and edit the nomination up to the end of the nomination period. It all worked rather well.
Well it’s award time again, but our web standards have changed. I’m no longer allowed to require registration (don’t ask), so the people submitting the nominations will basically just be filling out a form and submitting it. But since it’s a lengthy form, I need to create some way for people to save the form and continue it at a later time.
The suggestion from the head of IT was to create a “random unique identifier” that they could use to fetch their nomination. This is pretty easy using CreateUUID, but I’ve been told that the resulting ID number is “way too long”.
I thought about doing a listfirst to grab the first 8 digits, but I’m not sure how that diminishes the likelihood of coming up with a unique number.
Do your company “users” typically only use one machine to do this? For instance, does everyone just use their own machine at their desk (provided they only have one)? In any cases where users may share PCs this answer will not work but… Cookies are always an option to “remember” users. However, if any of the above listed scenarios are false then this will not work.
Maybe others can help add to this next idea but if you CreateUUID and that is “way too long” can you not then encrypt that value with certain encryption standards to generate a shorter value?
Most cases I can think of require users to be on the same PC and not share PCs. If cookies don’t work, you can create application variables based off the users IP address etc.
Just thinking out loud to offer anything that may help
Actually, now that I think about it longer… What if you just create an extra field in the database that you store the form information in called “xid” or something and make it a primary key identity field starting at 1. Then just display to the user that they are ID#: #xid# and that should be enough. As long as you don’t have people who like to poke around and enter random numbers that are not their own just to see and manipulate what other people vote. Now that I said that…probably scratch that idea unless you encrypt the ID and give them that…
Do you ask for any kind of unique information for each user?
e.g. an email address, postal address details?
Email is good because that’s got to be unique.
That aside why does the length of the CreateUUID() affect anything? Is that personal opinion or is there a technical restraint ( column field length / type ) why the UUID can’t be used. It’s a fair common way of dealing with these things :).
Here’s a nice function for creating a random string. Use this to create whatever length of id you need and check the output to make sure it is unique before you pass it on to the user.
We’re no longer allowed to ask for any sort of identifying information, otherwise I’d use email address like I did in the last “version” of this app. It’s sort of ridiculous, since we’ll still need to ask the people for some sort of information, otherwise how will you know who’s getting nominated?
The whole “point” of this is to get it past the scrutiny of the security people here. If they see “password/username” they get paranoid and worry that someone might somehow hack in to the app, find the users’ (encrypted) passwords, somehow decrypt them, then try to use them on other systems where the hacked user is theoretically using the same password. If we assigned credentials, that can’t happen (though no one has managed to explain to me why an assigned PW is bad, yet an assigned “unique ID” is just fine).
The length thing is someone’s random opinion. The full UUID is “too long for someone to jot down”. I think most people would copy-paste it somewhere, but that’s just me.
Yeah, the problem if just using the ID column is that people might fiddle around in other people’s records. But I could append the ID to a random number to ensure that it’s unique.
That works awesomely, thanks! I think that solves my problem, and I think I can reuse it for a bunch more things later on.
Our policy forces a password so long that most users just write it down on a post-it note and stick it under their monitor. I’m not sure how much more secure a 12-digit password is than an 8-digit one, all things considered.