I thought that was rather odd as well. I started in on PHP for a bit
during the summer and eventually dropped it after discovering that OO-PHP
is deprecated by those Zend folks (supposedly it's slow and there are no
destructor methods). I also didn't want to deal with their useless use of
Just to jump in here - as I understand it you can split a hash across
multiple threads if you preload it before apache forks. So load it in your
startup.pl and get it in memory prior to forking. It'll be part of the
shared memory since you aren't writing to it. Or at least that's how I
This isn't strictly a mod_perl thing but this is probably the safest way
to make this happen. This happens to be how I've created a secure (by my
definition. correct me if I get something wrong) web application.
Pipe everything through an SSL tunnel
The initial logon is username + password. A
Oh yes, changing IPs. I hear that WebTV terminals may have different IP
addresses per each HTTP request. I suppose the specific behaviour you want
on the event 'user A at station A is authenticated. user A at station B
attempts to authenticate'. I handle that by expiring the original session
I would have sent both to the client. The sequence would be *the* id and
is guaranteed to be uinique by the database (or whatever else is around
that does this reliably). The idea is that by combining the random secret
with the ID and sending the digest with that the ID number can't just be
(Anyone else, is there a module that already does this?)
That misses two things: random data is not unique and random data is
scarce.
The thread started where someone else wanted a cheap way to generate
difficult to guess and unique session ids. It went on around how using a
random function
I've been following this conversation and I'd like to clarify whether my
idea (since I and others want to do this as well) would be use an
incrementing counter for uniqueness. Then also store a bit of secret
randomness, concatenate both values together and create a digest hash.
That hash
