On 09/07/2011 03:19, Ron Savage wrote:
Hi Lyle
OK - As a first step, I've uploaded Module::Metadata::CoreList to CPAN.
Docs:
http://savage.net.au/Perl-modules/html/Module/Metadata/CoreList.html
Sample report:
http://savage.net.au/Perl-modules/html/module.metadata.corelist.report.html
On 07/05/2011 02:29 AM, Nicholas Bamber wrote:
The latest release of CGI::Session appears to be unauthorized. I can
find it at http://search.cpan.org/~markstos/CGI-Session-4.45/ but ifyou
click on permalink it disappears.
Thanks for the note.
I've now uploaded to 4.46 to address this issue.
On 07/07/11 01:45, Ron Savage wrote:
Hi Nick
On Wed, 2011-07-06 at 14:35 +0100, Nicholas Bamber wrote:
Ron,
You put an explicit version on every dependency. For example
Data::Dumper 2.128. That seems unnecessarily modern and Debian curently
only has 2.125. If we added the latest
On 07/07/2011 04:01 AM, Ron Savage wrote:
Hi Josh
On Wed, 2011-07-06 at 21:23 -0400, Joshua Miller wrote:
Hi all,
This is kinda picking at a sore spot for me, and I haven't seen any good
place to bring it up in the past.
I used to use 0 for all module versions, but that caused problems,
Hi Micael
On Thu, 2011-07-07 at 09:55 -0400, Michael Peters wrote:
On 07/06/2011 09:23 PM, Joshua Miller wrote:
If it's only the test code that uses it, IMO it shouldn't be a requirement.
Exactly. It's for this reason that build_requires was invented. That way
you can require certain
Hi Nick
On Wed, 2011-07-06 at 14:35 +0100, Nicholas Bamber wrote:
Ron,
You put an explicit version on every dependency. For example
Data::Dumper 2.128. That seems unnecessarily modern and Debian curently
only has 2.125. If we added the latest version as a package it might
need to be
Hi all,
This is kinda picking at a sore spot for me, and I haven't seen any good
place to bring it up in the past.
On Wed, Jul 6, 2011 at 8:45 PM, Ron Savage r...@savage.net.au wrote:
Hi Nick
On Wed, 2011-07-06 at 14:35 +0100, Nicholas Bamber wrote:
Ron,
You put an explicit version
Hi Josh
On Wed, 2011-07-06 at 21:23 -0400, Joshua Miller wrote:
Hi all,
This is kinda picking at a sore spot for me, and I haven't seen any good
place to bring it up in the past.
This is discussed now and again. There's nothing wrong in spelling out
your position.
I used to use 0 for all
On 07/07/2011 03:01, Ron Savage wrote:
OK - here's what I'll do.
I'll use perlbrew to install a fresh copy of 5.10.1.
My system Perl (5.10.1) is Debian's 6.0.2, but I won't use that, since I
may have upgraded modules before switching to perlbrew, even though
I /think/ I only ever used cpanm
Hi Lyle
On Thu, 2011-07-07 at 03:25 +0100, Lyle wrote:
On 07/07/2011 03:01, Ron Savage wrote:
OK - here's what I'll do.
I'll use perlbrew to install a fresh copy of 5.10.1.
My system Perl (5.10.1) is Debian's 6.0.2, but I won't use that, since I
may have upgraded modules before
The latest release of CGI::Session appears to be unauthorized. I can
find it at http://search.cpan.org/~markstos/CGI-Session-4.45/ but ifyou
click on permalink it disappears.
# CGI::Application community mailing list
##
Hi Nick
On Tue, 2011-07-05 at 07:29 +0100, Nicholas Bamber wrote:
The latest release of CGI::Session appears to be unauthorized. I can
find it at http://search.cpan.org/~markstos/CGI-Session-4.45/ but ifyou
click on permalink it disappears.
Have you considered the re-write: Data::Session
--
Hi Nick
On Tue, 2011-07-05 at 17:45 +0100, Nicholas Bamber wrote:
Ron,
I was commenting because the Debian Perl group's systems are confused
by this state of affairs. Whatever my personal opinions of the relevant
merits of CGI::Session and Data::Session the Debian package still needs
Ron/Jason,
Actually, anything and everything which give people information (on
which to base decisions pertaining to their own lives) helps.
Thanks for the information. This exactly describes my problem.
Mark refuses to release until I make changes he insists on.
The ostensible
Ron,
There's no point - Mark Stosberg refuses to release any more versions of
CGI::Session.
http://github.com/cromedome/cgi-session/blob/master/Changes
This looks like an abortive attempt to restart development. Are you
saying that Mark is trying to prevent further development, or is to
It wasn't an attempt to restart development, I was no longer in a
position to host the repo, so I moved it to github. People who were
maintainers and developers before still are.
That being said, I don't know why a release hasn't been made,
especially given how worthwhile some of the recent
Hi Nicholas, Jason
On Thu, 2010-10-14 at 13:04 -0500, Jason A. Crome wrote:
It wasn't an attempt to restart development, I was no longer in a
position to host the repo, so I moved it to github. People who were
maintainers and developers before still are.
Yep.
That being said, I don't know
On Tue, 10 Jan 2006 14:04:10 -0500 Perrin Harkins [EMAIL PROTECTED]
wrote:
value=3:1136895378:84eb13cfed01764d9c401219faa56d53
Excuse me, is there a Perl function or whatever that makes it possible
to generate such a string consisting of the letters and digits?
--
Best regards,
Strong.
I can't understand why You do not simply use a huge random ids?
Because random ne unique, and if you get one that isn't unique,
you will have problems. Random also doesn't mean someone can't get
lucky and hit one if they write a script to try IDs all day.
Thanks for explanation! I got it.
On Wed, 2006-03-08 at 17:13 +0300, Strong wrote:
I can't understand why You do not simply use a huge random ids?
Because random ne unique, and if you get one that isn't unique,
you will have problems. Random also doesn't mean someone can't get
lucky and hit one if they write a script to
On Wed, 2006-03-08 at 17:13 +0300, Strong wrote:
On Tue, 10 Jan 2006 14:04:10 -0500 Perrin Harkins [EMAIL PROTECTED]
wrote:
value=3:1136895378:84eb13cfed01764d9c401219faa56d53
Excuse me, is there a Perl function or whatever that makes it possible
to generate such a string consisting of the
On Tue, 10 Jan 2006 13:51:29 -0500 Perrin Harkins [EMAIL PROTECTED]
wrote:
The only other easy option appears to be using
CGI::Session::ID::incr.
There is also APR::UUID for mod_perl users, a database sequence, or
another UUID module.
And unless you protect the cookie somehow, users
Strong wrote:
I can't understand why You do not simply use a huge random ids?
How can you generate huge, truly random ids? In a multi-process (even
multi-server) environment, how can you guarantee that they are random without a
huge overhead of communication. That's the problem they were
On Tue, 2006-03-07 at 21:07 +0300, Strong wrote:
On Tue, 10 Jan 2006 13:51:29 -0500 Perrin Harkins [EMAIL PROTECTED]
wrote:
The only other easy option appears to be using
CGI::Session::ID::incr.
There is also APR::UUID for mod_perl users, a database sequence, or
another UUID module.
On Tue, 10 Jan 2006, Michael Graham [EMAIL PROTECTED] wrote:
I don't think there is an easy way for you to override generate_id() in
a way that will trick FormState into using a different value for its
ids. The sensible thing to do is to patch CAP::FormState to use
sequential ids.
OK some
On Mon, 9 Jan 2006, Michael Graham [EMAIL PROTECTED] wrote:
One point to remember is that these form state ids are specific to a
particular user session. So any potential collision would have to be
with an existing state for the *same* user.
For this reason, tampering is less of an issue as
Michael Graham [EMAIL PROTECTED] wrote:
If you're worried about md5 collisions, I don't think you can ignore the
issue of session collisions (at least until CAP::FormState uses
sequential ids). If a new user accidentally gets an existing user's
session, the new user also gets a bunch of old
On Tue, 2006-01-10 at 13:09 -0500, Michael Graham wrote:
Actually, thinking about it further, this would still be an issue even
if CAP::FormState used sequential ids, since an md5 collision with the
session could cause a race condition with the counter
If there is a collision with session IDs
On Tue, 2006-01-10 at 10:39 -0500, Michael Graham wrote:
I think the way to do anti-tampering is to keep a pseudo-random
string in the user's session under 'form_state_secret'. Then take this
string along with the form state id and the current time and make a
hash. Add the time and the hash
On 1/10/06, Perrin Harkins [EMAIL PROTECTED] wrote:
On Tue, 2006-01-10 at 10:39 -0500, Michael Graham wrote:
I think the way to do anti-tampering is to keep a pseudo-random
string in the user's session under 'form_state_secret'. Then take this
string along with the form state id and the
Hello group, I'm using CAP::FormState to protect hidden form fields.
Everything appears to work OK, but I notice a large amount of
information build-up in the a_session field of the sessions table (also
using CGI::Session with MySQL for authentication). In particular there
is a large
2006 07:36
To: cgiapp@lists.erlbaum.net
Subject: [cgiapp] CGI::Session::ID::md5-generate_id data collision
Hello group, I'm using CAP::FormState to protect hidden form fields.
Everything appears to work OK, but I notice a large amount of
information build-up in the a_session field
On Mon, 2006-01-09 at 18:36 +, RA Jones wrote:
I have had some communication with Michael (module author) on a related
theme, and he tells me the module uses the
CGI::Session::ID::md5-generate_id routine. Because the runmodes rely on
the information retrieved from the cap_form_state
Perrin Harkins [EMAIL PROTECTED] wrote:
On Mon, 2006-01-09 at 18:36 +, RA Jones wrote:
it got me
wondering what the chances of data collision are with this method - ie
what chance the key
'form_state_cap_form_state_bf9a49cb6debf1f1dd388d81550fb648' for example
would be regenerated
Perrin Harkins [EMAIL PROTECTED] wrote:
On Mon, 2006-01-09 at 16:56 -0500, Michael Graham wrote:
Is this the best/easiest way of guaranteeing unique session ids with
CAP::Session?
It's one good way. Others would be a database sequence or the GUID/UUID
stuff on CPAN, but that's probably
On Mon, 2006-01-09 at 17:55 -0500, Michael Graham wrote:
Ah, right. Hmmm... so maybe the best solution is to add the HMAC
feature to CGI::Session, somehow. Maybe a new 'hmac' driver type:
my $sess = CGI::Session-new(id:incr;hmac:sha1, $query, {
HMAC_Secret = 'abc123',
});
This is something you would normally do at a cookie managing level, not
at the session level. I guess you could do it here if CGI::Session has
an API flexible enough for it.
Fair enough. The only advantage to doing it at the session level in
this case is that CGI::Session tries to be clever
Jason A. Crome wrote:
Finally!
The public Subversion repository for CGI::Session is set up and working.
You can access the repository at one of the following locations:
svn://svn.cromedome.net/CGI-Session
http://svn.cromedome.net
Every time I do a check out I get this:
[EMAIL
To be honest, I'm not entirely sure what's causing that :( I'll see
what I can figure out this afternoon and hopefully be able to make this
go away.
Is anyone else experiencing this
Jason
Michael Peters wrote:
Jason A. Crome wrote:
Finally!
The public Subversion repository for
On 07/07/05, Jason A. Crome [EMAIL PROTECTED] wrote:
To be honest, I'm not entirely sure what's causing that :( I'll see
what I can figure out this afternoon and hopefully be able to make this
go away.
Is anyone else experiencing this
I just gave it a try and got the exact same error
I have no idea what caused this. . . I ended up uninstalling the FreeBSD
port and getting a fresh tarball from the Subversion web site. After a
quick recompile and a little testing, all seems to be well.
Let me know if anyone experiences further problems.
Jason
Paul Campbell wrote:
On
Jason A. Crome wrote:
I have no idea what caused this. . . I ended up uninstalling the FreeBSD
port and getting a fresh tarball from the Subversion web site. After a
quick recompile and a little testing, all seems to be well.
Cool, that fixed it, thanks!
--
Michael Peters
Developer
Plus
Finally!
The public Subversion repository for CGI::Session is set up and working.
You can access the repository at one of the following locations:
svn://svn.cromedome.net/CGI-Session
http://svn.cromedome.net
I have provided anonymous read-only access. Write-enabled accounts will
be handed
On 2005-07-05, Michael Peters [EMAIL PROTECTED] wrote:
I believe this is already supported in 4.x:
use CGI::Session;
$session = new CGI::Session(id:static, $ENV{UNIQUE_ID});
Wow, I didn't know that you could do that. Is it new in 4.x?
Yes.
Would it be worthwhile for me to go
Wow, you've been busy ;) Not leaving much for the rest of us! /tease
To give you all an update, I had a hard drive fail in the box I was
going to host the CGI::Session project on. Given the age of the box, I
figured it was doomed to entirely fail at some point, so I swapped in
another box.
Hello,
I've gone ahead and started hacking on CGI::Session.
I've set up a darcs repo here:
http://mark.stosberg.com/darcs_hive/cgi-session/
I've using darcs2rss to provide an RSS feed of the changes, updated
hourly.
http://mark.stosberg.com/darcs_hive/cgi-session/changes.rss
The primary
Hi Folks
Has anyone written an Oracle module for CGI::Session?
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 29/06/2005
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company
-
Web Archive:
I can't remember specifically the recent issues that have cropped up here
re: CGI::Session, but I did just notice that CGI::Session has had 3 updates
in the last 5 days. The first updates to the module in the last 21 months.
So it looks like the author might be in a mood to fix any of the issues
The main problem people were having had to do with using CGI::Simple
and CGI::Session together. It looks like the issues have been fixed
in CGI::Session [1], so that any module that has a param and cookie
method that works like CGI.pm will work properly.
Good news, as that means I can remove the
On Thu, 13 Jan 2005, Cees Hek wrote:
Well, it sounds like maybe you are passing in a handle to CGI::Session
that is closed, or your connection parameters are invalid. I haven't
used SQLite, so I am not familiar with it, but if you show us a small
code snippet that demonstrates the problem,
and of course I sent the wrong code.
The UPDATE looks correctly like this:
$dbh-do(UPDATE sessions SET uid=? WHERE id=?,
undef,
$user-id, $self-session-id);
the one I sent earlier is already a work around I implemented.
Gabor
Gabor Szabo wrote:
Hi,
I am not sure what is the source of the problem, I hope someone
can point me to a good solution.
I'am using the CA:Plugin::Session and using Class::DBI with SQLite.
As I'd like to use the SQLite database to hold the session
data in cgiapp_init I have this code:
my $dbh =
On Tue, 2 Nov 2004, Michael wrote:
$dbh-do(UPDATE users SET session=? WHERE id=?,
undef,
$self-session-id, $user-id);
This seems to work as if I check immeditely afterwords I can see
the data updaed but then by the time the web page shows up the
Gabor Szabo wrote:
On Tue, 2 Nov 2004, Michael wrote:
$dbh-do(UPDATE users SET session=? WHERE id=?,
undef,
$self-session-id, $user-id);
This seems to work as if I check immeditely afterwords I can see
the data updaed but then by the time the web page shows up the
I think it would be preferable if I could keep the user id in the
sessions table.
I wouldn't add extra columns to the session table.
CGI::Session is going to be using it and I expect that it's
the cause of your problems.
If you do need extra columns though, check out Mark's
Jason A. Crome wrote:
I think it would be preferable if I could keep the user id in the
sessions table.
I wouldn't add extra columns to the session table.
CGI::Session is going to be using it and I expect that it's
the cause of your problems.
If you do need extra columns though, check out
On Tue, 2 Nov 2004 15:02:11 +0200 (IST), Gabor Szabo [EMAIL PROTECTED] wrote:
The problem arises when I want to add further information to the
sessions table. I'd like to be able to control how many times each user
is logged on at the same time. (Usually that will be = 1 as we don't
want
Cees Hek wrote:
On Tue, 2 Nov 2004 15:02:11 +0200 (IST), Gabor Szabo [EMAIL PROTECTED] wrote:
The problem arises when I want to add further information to the
sessions table. I'd like to be able to control how many times each user
is logged on at the same time. (Usually that will be = 1 as we
Cees Hek wrote:
On Tue, 02 Nov 2004 17:23:16 -0500, Michael [EMAIL PROTECTED] wrote:
Cees Hek wrote:
I could be wrong, but that seems really insecure. After login, the user
could change their cookie (or session id) to be some other user's name
and then masquarade as the other user (changing
On 2004-10-19, William McKee [EMAIL PROTECTED] wrote:
I second this. I have sent a couple requests directly to the author and
never heard back from him. There are at last count 16 outstanding issues
filled in RT. It's too bad that these very popular modules are not being
maintained.
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Stosberg
Sent: Tuesday, October 19, 2004 1:04 PM
To: [EMAIL PROTECTED]
Subject: [cgiapp] CGI::Session maintainer help needed. (was:
Re: CGI::Application::Plugin::Session - new session every call)
On 2004-10-19, William McKee [EMAIL PROTECTED] wrote
: [cgiapp] CGI::Session maintainer help needed.
(was: Re: CGI::Application::Plugin::Session - new session every call)
On Tue, Oct 19, 2004 at 01:24:28PM -0500, Jason A. Crome wrote:
I authored an ODBC driver for CGI::Session some time ago and have
offered repeatedly to help maintain or take over
On Tue, Oct 19, 2004 at 01:24:28PM -0500, Jason A. Crome wrote:
I've pondered the latter at length. What do the rest of you think?
Personally, I'd rather see the existing modules maintained instead of
forked. I don't know what the procedures are for getting access to
modules of a non-responding
--
Jason A. Crome
Senior Software Engineer, DEVNET, Inc.
E-Mail: [EMAIL PROTECTED]
http://www.devnetinc.com
-Original Message-
From: William McKee [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 2:14 PM
To: [EMAIL PROTECTED]
Subject: Re: [cgiapp] CGI::Session maintainer
On Tue, 19 Oct 2004 13:57:05 -0500, Jason A. Crome wrote:
Hi Jason
I too think the ideal is that the original author do the work.
So how to track him down? I suggest you announce something on comp.lang.perl.modules,
in case he - or even someone who knows where he is - reads that list.
65 matches
Mail list logo
