On Thu, 2009-09-17 at 23:12 +0200, Torsten Foertsch wrote:
On Thu 17 Sep 2009, Kiran Kumar wrote:
There is also Padre (http://padre.perlide.org/) , You can write
plugins and customize to your needs, there are already lots of
plugins available
On Wed, 16 Sep 2009, Igor Chudov wrote:
On Wed, Sep 16, 2009 at 11:05 AM, Michael Peters mpet...@plusthree.comwrote:
Reducing DB usage is more important than this. Also, before you go down
that road you should look at adding a caching layer to your application
(memcached is a popular choice).
3) Being enabled by item 2, add more webservers and balancers
4) Create a separate database for cookie data (Apache::Session objects)
??? -- not sure if good idea --
I've never seen the need to do that. In fact, I would suggest you drop
sessions altogether if you can. If you need any
-Original Message-
From: Brad Van Sickle bvansick...@gmail.com
Sent: Sep 17, 2009 12:13 AM
To: Michael Peters mpet...@plusthree.com
Cc: Mod_Perl modperl@perl.apache.org
Subject: Re: Ways to scale a mod_perl site
but I was unaware that there might be
an option for doing this without
Michael, you inspired me to reimplement cookies this way. For my site, the
cookie table is the most frequently updated one (even though I do not grant
cookies to search engines). I will try to use this kind of implementation.
Even now, my users like the fact that they can stay signed on forever,
This?
http://search.cpan.org/~jkrasnoo/ApacheCookieEncrypted-0.03/Encrypted.pm
Catalyst has a plugin:
http://search.cpan.org/~lbrocard/Catalyst-Plugin-CookiedSession-0.35/lib/Catalyst/Plugin/CookiedSession.pm
Thanks.
On Fri, Sep 18, 2009 at 9:06 PM, Igor Chudov ichu...@gmail.com wrote:
On Fri, Sep 18, 2009 at 8:12 AM, Fayland Lam fayl...@gmail.com wrote:
This?
http://search.cpan.org/~jkrasnoo/ApacheCookieEncrypted-0.03/Encrypted.pmhttp://search.cpan.org/%7Ejkrasnoo/ApacheCookieEncrypted-0.03/Encrypted.pm
Catalyst has a plugin:
On 09/18/2009 09:14 AM, Igor Chudov wrote:
I realized that there is something I am missing. Sometimes I may need to
put something into the session after I did $cgi-start_html. I can do it
if the cookie is only a session ID, with session data stored in mysql.
This might be a larger
On Fri 18 Sep 2009, Igor Chudov wrote:
But how can I change the cookie AFTER I called $cgi-start_html?
As long as there is nothing sent out on the wire you can add headers.
When the response header is gone you can't. start_html() only generates
a string as far as know. So it depends upon when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
unsubscribe
Jeff Peng wrote:
-Original Message-
From: Brad Van Sickle bvansick...@gmail.com
Sent: Sep 17, 2009 12:13 AM
To: Michael Peters mpet...@plusthree.com
Cc: Mod_Perl modperl@perl.apache.org
Subject: Re: Ways to scale a
I was very excited by the suggestion to use cookies to store the entire
session information, and to keep it safe by means of base64 encoding and MD5
hash with a secret salt, for storing session information securely on the
client.
I realized that there is something I am missing. Sometimes I may
Igor == Igor Chudov ichu...@gmail.com writes:
Igor I was very excited by the suggestion to use cookies to store the entire
Igor session information, and to keep it safe by means of base64 encoding and
Igor MD5 hash with a secret salt, for storing session information securely on
Igor the client.
On 09/18/2009 10:33 AM, Randal L. Schwartz wrote:
Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that
cookies should really just be used to distinguish one browser from another,
and hold everything server-side instead for far better security and
flexibility.
I
On Wed, 16 Sep 2009, Michael Peters wrote:
On 09/16/2009 12:13 PM, Brad Van Sickle wrote:
Can I get you to explain this a little more? I don't see how this could
be used for truly secure sites because I don't quite understand how
storing a hash in a plain text cookie would be secure.
If you
Michael == Michael Peters mpet...@plusthree.com writes:
Michael On 09/18/2009 10:33 AM, Randal L. Schwartz wrote:
Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that
cookies should really just be used to distinguish one browser from another,
and hold everything
On 09/18/2009 11:13 AM, Tina Mueller wrote:
How does the user invalidate that session? (in case the cookie leaked
or something like that). Or how can the website owner log out a certain
user?
When you generate the hash for the cookie, you can also include the
timestamp and the IP address of
All due respect, but hat's a little condescending... I generally cringe
when I hear anyone advocating that there is one right way to do things
that should be used in every instance
In addition to Michael's points (which are totally valid) I would add
that your solution is great for
On 09/18/2009 11:15 AM, James Smith wrote:
But cookies are in general not big enough to store the information that
a user would store on a website!
I'm not talking about eliminating a permanent data store for your users.
I'm talking about replacing the session specific things. How much
On 09/18/2009 11:19 AM, Randal L. Schwartz wrote:
Yes. Welcome to phase 2. Eventually, you'll enter phase 3.
I used to be a phase 3 convert and then some really smart people
convinced me otherwise :)
--
Michael Peters
Plus Three, LP
Brad Van Sickle bvansick...@gmail.com writes:
3) Being enabled by item 2, add more webservers and balancers
4) Create a separate database for cookie data (Apache::Session objects)
??? -- not sure if good idea --
I've never seen the need to do that. In fact, I would suggest you
drop
Tina Mueller apa...@s05.tinita.de writes:
On Wed, 16 Sep 2009, Michael Peters wrote:
[...]
If you need to store per-session data about a client that the client
shouldn't be able to see, then you just encrypt that data, base-64
encode it and then put it into a cookie.
How does the user
It amounts to shared private key security.
Each web server, for instance, is configured with the key abcd1234
The session looks like
{ username = 'dog'
, group = 'canid'
, premium = 0
, login_time = 1253289574
}
I serialize that into a string with join '|', (map { $_, $session-{$_} } sort
On Sep 17, 2009, at 11:09 PM, Tuomo Salo wrote:
Heck, every CGI perl script on our server uses the same code, which
is
defined in the 'appname-defaults' file for each application.
I am going to hazard a guess that the other scripts run under mod_perl
(as opposed to CGI) too. If not, then
Hi Randal, nice to see you. Your suggestion is where I am coming FROM: right
now the cookie is only a key into the mysql table which holds session data.
What I want is to stop using that table altogether and let the browser hold
the information, in a manner that is straightforward, flexible and
On 09/18/2009 12:16 PM, Ihnen, David wrote:
Its security through obscurity admittedly - security in that you can't see my
code, methodology, or shared secret configuration.
No it's not really through obscurity. Even if someone found out your
method of serialization your data is still safe.
On Fri, Sep 18, 2009 at 10:51 AM, Michael Peters mpet...@plusthree.comwrote:
On 09/18/2009 11:15 AM, James Smith wrote:
But cookies are in general not big enough to store the information that
a user would store on a website!
I'm not talking about eliminating a permanent data store for
Igor == Igor Chudov ichu...@gmail.com writes:
Igor In my case, in almost all instances, the only thing I would want to
Igor store is authenticated userid.
The problem with that is public web browsers. You *cannot* ensure the
expiration of an auth cookie, so you'll have to have some sort of
On Fri, Sep 18, 2009 at 10:13 AM, Tina Mueller apa...@s05.tinita.de wrote:
On Wed, 16 Sep 2009, Michael Peters wrote:
On 09/16/2009 12:13 PM, Brad Van Sickle wrote:
Can I get you to explain this a little more? I don't see how this could
be used for truly secure sites because I don't quite
On 09/18/2009 12:57 PM, Randal L. Schwartz wrote:
The problem with that is public web browsers. You *cannot* ensure the
expiration of an auth cookie, so you'll have to have some sort of server-side
data to say this user most recently authenticated at this time, so I still
trust him.
Why does
On Fri, Sep 18, 2009 at 12:11 PM, James Smith j...@sanger.ac.uk wrote:
Igor Chudov wrote:
On Fri, Sep 18, 2009 at 10:13 AM, Tina Mueller apa...@s05.tinita.dewrote:
On Wed, 16 Sep 2009, Michael Peters wrote:
On 09/16/2009 12:13 PM, Brad Van Sickle wrote:
Can I get you to explain this
Hey there,
i've a strange problem... According to the mod_perl 2.0 server
configuration pages, the following should work:
Location /__ias/jobserver
SetHandler perl-script
PerlInterpStart 1
PerlInterpMax 1
PerlInterpMaxRequests 1000
PerlResponseHandler
While many great minds are here, I would like to focus on one point for a
moment, which in my experience, has been the most critical:
The database
Before I were to ask any other of your questions (all of which were valid),
I would ask myself:
- What kind of database tables am I implementing?
Bruce Johnson wrote:
I'm getting this error:
[Thu Sep 17 10:52:13 2009] [error] Undefined subroutine
ModPerl::ROOT::ModPerl::PerlRunPrefork::home_oraweb_perl_avi_login_2epl::PrintHeader
called at /home/oraweb/perl/avi/login.pl line 43, FH1 line 71.\n
[Thu Sep 17 10:52:13 2009] [error]
Hi all,
I searched and googled around for a while but couldn't find a solution for
the following question.
We're using ModPerl::Registry (PerlOptions +ParseHeaders)
in combination with mod_perl to serve our pages in a CGI like
environment. This has the advantage for us to have only a very very
On Sep 16, 2009, at 9:13, Brad Van Sickle wrote:
I've never seen the need to do that. In fact, I would suggest you
drop sessions altogether if you can. If you need any per-session
information then put it in a cookie. If you need this information
to be tamper-proof then you can create a
On page http://perl.apache.org/docs/2.0/user/config/
config.html#mod_perl_Directives_Argument_Types_and_Allowed_Location
you can see the following line in the table that defines the scope of
the various directives:
PerlInterpStart TAKE1 SRV
SRV means server scope which to
On Fri, Sep 18, 2009 at 1:34 AM, Clinton Gormley cl...@traveljury.com wrote:
I'm surprised that nobody has mentioned EPIC, the Perl plugin for
Eclipse. It works really really well, at least as well as the Java
version (although it can't do as much prediction as Java can because of
the nature
37 matches
Mail list logo
