On Tue, 31 May 2016 19:13:25 +0200
demerphq wrote:
>
> If it can be replicated on a command line then yes.
>
It could not be replicated on the command line; I tried this, and got 10M
unique keys :
@arsene:~$ perl -le '%h=();for (1..10_000_000) {my $session_id = join "",
map +(0..9,"a"..
On Tue, 31 May 2016 18:59:46 +0200
André Warnier wrote:
> But now you have a 32-bit machine + OS, and a 32-bit perl, right ?
now it's a 64-bit machine + OS. I use standard distribution packages for
everything.
I installed qemu-kvm and created a 32-bit VM guest on it to try and reproduce
the p
On 27 May 2016 at 09:29, André Warnier wrote:
> On 26.05.2016 16:01, Vincent Veyron wrote:
>>
>> On Mon, 16 May 2016 16:38:18 +0200
>> Vincent Veyron wrote:
>>
>>> Out of five different servers, the code works fine on four machines, and
>>> a different token is generated every time the page is lo
On 31.05.2016 18:40, Vincent Veyron wrote:
On Fri, 27 May 2016 09:29:36 +0200
André Warnier wrote:
The above strongly hints at some flaw in the srand() of perl, when called by a
32-bit
perl, on a 64-bit OS/machine.
Maybe it is worth passing this info along to the perl (language) developers,
On Fri, 27 May 2016 09:29:36 +0200
André Warnier wrote:
>
> The above strongly hints at some flaw in the srand() of perl, when called by
> a 32-bit
> perl, on a 64-bit OS/machine.
> Maybe it is worth passing this info along to the perl (language) developers,
> at www.perl.org ?
>
Sorry for
On 26.05.2016 16:01, Vincent Veyron wrote:
On Mon, 16 May 2016 16:38:18 +0200
Vincent Veyron wrote:
Out of five different servers, the code works fine on four machines, and a
different token is generated every time the page is loaded or re-loaded. On one
server however, a previous token is b
On Mon, 16 May 2016 16:38:18 +0200
Vincent Veyron wrote:
> Out of five different servers, the code works fine on four machines, and a
> different token is generated every time the page is loaded or re-loaded. On
> one server however, a previous token is being re-used
Hi,
The faulty server was
On Wed, 18 May 2016 09:35:45 -0400
Lathan Bidwell wrote:
> Is it possible that its not a problem of the rand, but a problem of the ||=
> ?
>
> Try debugging the value before you set it. It could be a scoping issue
> where the old value stays in the variable and then ||= doesn't overwrite it.
>
Is it possible that its not a problem of the rand, but a problem of the ||=
?
Try debugging the value before you set it. It could be a scoping issue
where the old value stays in the variable and then ||= doesn't overwrite it.
*Lathan Bidwell*
On Wed, May 18, 2016 at 9:08 AM, Vincent Veyron wr
On Wed, 18 May 2016 09:12:17 +0200
André Warnier wrote:
> Maybe you can try a BEGIN block. If I remember correctly, under mod_perl (if
> you run under
> "registry" to keep the compiled cgi-bin in memory), a BEGIN block should be
> run only once,
> when the script is first compiled (by this ch
On 18.05.2016 01:23, Vincent Veyron wrote:
On Tue, 17 May 2016 20:41:28 +0200
demerphq wrote:
If you fork before you call (s)rand then each child process will have
their own copy of the flag, which will be false, and thus will cause
srand() to be called in the subprocess properly.
So now I'
On Tue, 17 May 2016 20:41:28 +0200
demerphq wrote:
>
> If you fork before you call (s)rand then each child process will have
> their own copy of the flag, which will be false, and thus will cause
> srand() to be called in the subprocess properly.
>
So now I'm lost : I understand this as meaning
On 17 May 2016 at 20:37, André Warnier wrote:
> On 17.05.2016 20:26, demerphq wrote:
>>
>> On 17 May 2016 at 20:23, demerphq wrote:
>>>
>>> On 16 May 2016 at 20:03, Bruce Johnson
>>> wrote:
> On May 16, 2016, at 10:15 AM, André Warnier (tomcat)
> wrote:
>
>
> join
On 17.05.2016 20:26, demerphq wrote:
On 17 May 2016 at 20:23, demerphq wrote:
On 16 May 2016 at 20:03, Bruce Johnson wrote:
On May 16, 2016, at 10:15 AM, André Warnier (tomcat) wrote:
join "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32 ;
looks at first sight to me like quite i
On 17 May 2016 at 15:10, André Warnier wrote:
> On 17.05.2016 14:11, Vincent Veyron wrote:
>>
>> On Tue, 17 May 2016 10:16:43 +0200
>> André Warnier wrote:
>>>
>>>
>>> I don't see above any signifiant difference in configuration between the
>>> servers, apart
>>> from the fact that the "faulty" s
On 17 May 2016 at 20:23, demerphq wrote:
> On 16 May 2016 at 20:03, Bruce Johnson wrote:
>>
>>> On May 16, 2016, at 10:15 AM, André Warnier (tomcat)
>>> wrote:
>>>
>>>
>>> join "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32 ;
>>>
>>> looks at first sight to me like quite inefficient a
On 16 May 2016 at 20:03, Bruce Johnson wrote:
>
>> On May 16, 2016, at 10:15 AM, André Warnier (tomcat) wrote:
>>
>>
>> join "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32 ;
>>
>> looks at first sight to me like quite inefficient and probably likely to
>> generate the same string regul
On 17.05.2016 14:11, Vincent Veyron wrote:
On Tue, 17 May 2016 10:16:43 +0200
André Warnier wrote:
I don't see above any signifiant difference in configuration between the
servers, apart
from the fact that the "faulty" server runs a 64-bit version of perl.
Sorry : slightly digressive rant a
Your test are on the command line, not inside apache and thus more or less
worthless.
As André clearly showed the issue is almost certainly with the way srand is
being called
inside apache
Add a call to srand with something suitably random from time pid and maybe
/dev/random
INSIDE apache bef
On Tue, 17 May 2016 10:16:43 +0200
André Warnier wrote:
>
> I don't see above any signifiant difference in configuration between the
> servers, apart
> from the fact that the "faulty" server runs a 64-bit version of perl.
Sorry : slightly digressive rant about the fact that every time I compar
On 17.05.2016 08:28, Vincent Veyron wrote:
On Mon, 16 May 2016 22:45:14 +
"Bruce Johnson" wrote:
I don’t think it would be likely for Vincent to ever see this once, let alone
have it rise to the issue of a problem if it were strictly about non-randomness
of the rand() function.
Inde
On Mon, 16 May 2016 22:45:14 +
"Bruce Johnson" wrote:
>
> I don’t think it would be likely for Vincent to ever see this once, let alone
> have it rise to the issue of a problem if it were strictly about
> non-randomness of the rand() function.
>
Indeed : I also use the function to gener
> On May 16, 2016, at 1:26 PM, André Warnier wrote:
>
> I may be wrong, but at least intuitively, this does not seem to be an optimal
> way to obtain a 32-char long random key.
>
It’s about 30% slower to run
join "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32;
versus
$r= join ""
On 16.05.2016 20:03, Bruce Johnson wrote:
On May 16, 2016, at 10:15 AM, André Warnier (tomcat) wrote:
join "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32 ;
looks at first sight to me like quite inefficient and probably likely to
generate the same string regularly, even if it does
> On May 16, 2016, at 10:15 AM, André Warnier (tomcat) wrote:
>
>
> join "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32 ;
>
> looks at first sight to me like quite inefficient and probably likely to
> generate the same string regularly, even if it does not look that way.
> (The only
On 16.05.2016 16:38, Vincent Veyron wrote:
Hi,
I use the code shown here :
http://pastebin.com/6YL9FWGX
in a mod_perl handler.
At line 57, $args->{_token_id} ||= ... generates a random token that is used to
uniquely identify the request (users may reload the URL in two different windows),
a
Hi,
I use the code shown here :
http://pastebin.com/6YL9FWGX
in a mod_perl handler.
At line 57, $args->{_token_id} ||= ... generates a random token that is used to
uniquely identify the request (users may reload the URL in two different
windows), and added to the request's arguments.
Out of
27 matches
Mail list logo
