Hi Dave,

As far as I can see, sessions per se would not work, because:

- These URL's are typically sent in email messages (so the session is not initiated by logging into a site)
- There is no one-to-one mapping from users to sessions (the same URL may be sent to many users, and users are not required to authenticate on the site)

In an general sense, I suppose it would be possible to set up a persistent hash where the key is a unique ID and the value is the parameters. When generating the email, the parameters would be stripped off the URL, and stored in the hash against a new unique key. The key would then be added to the URL. When the CGI is run, it would look up the values against the key.

My objection to this is it's not possible to tell when a given hash entry can be safely deleted.

regards,

-- Michael Snell
-- michael@snell.com

In an general sense, I suppose it would be possible to set up a persistent hash where the key is a unique ID and the value is the parameters. When generating the email, the parameters would be stripped off the URL, and stored in the hash against a new unique key. The key would then be added to the URL. When the CGI is run, it would look up the values against the key.

That's pretty much what I envisaged, but why not have two hashes going both ways. The keys of the other hash are the params and the value is the unique id. Then when you generate the email look to see if the id for this combination of params already exists, and if it doesn't generate one and insert a record in both hashes

My objection to this is it's not possible to tell when a given hash entry can be safely deleted.

I think that under my scheme, as you're reusing the same id for the same combination of parameters you won't need to delete entries from the hashes.

I may be misunderstanding the problem tho'.

--
<http://www.dave.org.uk>

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

Reusing the hash keys is a good idea, but where one of the parameters is, for instance, an key referring to an entry in a database table, which is constantly incremented, then new hash entries will be created on an ongoing basis.

-- Michael Snell
-- michael@snell.com

You do not say how many options there are for each parameter. If there are only a small number of responses then the call could be replaced by a one or two character sequence. A number of these could be concatenated into a simple string.

Caillte,

http://www.server.com/cgi-bin/script/script.pl?Mode=view&Area=12345&Su
+bArea=12345
[download]

would be a fairly genernal example.

regards,

-- Michael Snell
-- michael@snell.com

I'm a little confused at this point. I think davorg's idea is a pretty good one, as it makes it possible to pass around the session ID and reconstruct the data on the server side. I suppose you could also construct the session-ID using a two-way algorithm rather than MD5 (i.e. use a method you can decode with the proper key ... the RSA algorithm isn't patented any more =)

What do you want to consider a "safe" deletion? After a certain time? (store an expiration date in the database for each hash) When a certain percentage of (unique) respondents have used the session ID? (Ditto, you update the dB for each unique respondent).

Philosophy can be made out of anything. Or less -- Jerry A. Fodor