Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ModPerl

Authentication logic [was: Changing browser URL based on condition]

 

 

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded


vv.lists at wanadoo

Jul 12, 2011, 5:45 AM

Post #1 of 14 (1398 views)
Permalink
Authentication logic [was: Changing browser URL based on condition]

Hi list,

In a recent thread, this exchange took place :

Le lundi 11 juillet 2011 à 21:54 +0200, André Warnier a écrit :

> Szekeres, Edward wrote:
> > It seems to be just an attempt to do what is already done in Apache2::AuthCookie (CPAN), which encapsulates a server side authentication.
> >
> >
> +1
> Exactly.
> And I would add that before you start trying to implement you own authentication logic,
> you should really think twice. HTTP authentication is a lot more messy than what you
> would at first think, and you should first have a look at some existing CPAN modules like
> the one mentioned above, and browse the code to understand what they are doing and why. Or
> just use them, they work.
>

I've been meaning to ask a related question to the list for a while. My
logic for session authentication is thus:

Login is handled by login.pm which checks username/password pair against
database.

if ( valid pair ) { set session_id and time_to_live; set
cookie=session_id; store session_id and some parameters in a file via
Storable.pm; redirect to Home page } else { serve login again }

For all requests except login :

1 - Headerparser retrieves the session_id via the cookie, and reads the
session file.
If ( session_id is unknown or time_to_live exceeded ) then { serve
login } else { serve requested page }

2 - perlhandler generates content

3 - Filter processes content and resets time_to_live of session, stores
it back in file

The relevant modules are visible here :
login : http://vincentveyron.com/tmp/login.pm
headerparser : http://vincentveyron.com/tmp/get_session_id.pm
filter : http://vincentveyron.com/tmp/html_head_and_tail.pm

My questions :

-Is there anything wrong with my process?

-What does Apache2::AuthCookie do that I don't already have?


--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres et des contentieux pour le service juridique


perrin at elem

Jul 13, 2011, 10:19 AM

Post #2 of 14 (1364 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

On Tue, Jul 12, 2011 at 8:45 AM, Vincent Veyron <vv.lists [at] wanadoo> wrote:
> -Is there anything wrong with my process?

If it's working for you, then it sounds fine. Needing to invoke
mod_perl on every hit could be bad if you're trying to protect a lot
of otherwise static pages, but it doesn't sound like you are. The
file storage of sessions is also limiting (i.e. no clustering), but if
you aren't having trouble with it, no need to change it.

> -What does Apache2::AuthCookie do that I don't already have?

It might have better cookie security. Mostly it's just the general
advantage of using shared open source code over in-house code that has
no other users improving and debugging it.

- Perrin


vv.lists at wanadoo

Jul 14, 2011, 8:21 AM

Post #3 of 14 (1359 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

Le mercredi 13 juillet 2011 à 13:19 -0400, Perrin Harkins a écrit :
> On Tue, Jul 12, 2011 at 8:45 AM, Vincent Veyron <vv.lists [at] wanadoo> wrote:
> > -Is there anything wrong with my process?
>
> If it's working for you, then it sounds fine. Needing to invoke
> mod_perl on every hit could be bad if you're trying to protect a lot
> of otherwise static pages, but it doesn't sound like you are.


Indeed, all pages are dynamic; this is a case management app, so every
page requires queries from the database

> The
> file storage of sessions is also limiting (i.e. no clustering), but if
> you aren't having trouble with it, no need to change it.
>

My needs are very modest for the time being, so I did not investigate
this part at all, I must say.

Could you explain (very briefly) how clustering prevents file storage of
a session?


> > -What does Apache2::AuthCookie do that I don't already have?
> It might have better cookie security.
> Mostly it's just the general
> advantage of using shared open source code over in-house code that has
> no other users improving and debugging it.

Well, I'll look into it more. Thanks for your input.


--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres et des contentieux pour le service juridique


perrin at elem

Jul 14, 2011, 8:34 AM

Post #4 of 14 (1361 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

On Thu, Jul 14, 2011 at 11:21 AM, Vincent Veyron <vv.lists [at] wanadoo> wrote:
> Could you explain (very briefly) how clustering prevents file storage of
> a session?

A cluster in this case means multiple servers, so they don't share a
filesystem. There are ways to share files of course, but the common
solution is to put your session data in a database with remote access.

- Perrin


vv.lists at wanadoo

Jul 14, 2011, 9:57 AM

Post #5 of 14 (1358 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

Le jeudi 14 juillet 2011 à 11:34 -0400, Perrin Harkins a écrit :
> On Thu, Jul 14, 2011 at 11:21 AM, Vincent Veyron <vv.lists [at] wanadoo> wrote:
> > Could you explain (very briefly) how clustering prevents file storage of
> > a session?
>
> A cluster in this case means multiple servers, so they don't share a
> filesystem. There are ways to share files of course, but the common
> solution is to put your session data in a database with remote access.
>

This is what I first did, using Apache::Session. But I noticed the call
to tie was very slow (response time around 70ms with it, 15ms without
it), so I changed for Storable because filesystem reads were much
faster.

Also, I did not find how to store a hash in the database without tie. I
read it's possible to use Data::Dumper to write the data in a field and
read it as Perl code. Would that be a way to do it?

--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres et des contentieux pour le service juridique


mpeters at plusthree

Jul 14, 2011, 10:02 AM

Post #6 of 14 (1361 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

On 07/14/2011 12:57 PM, Vincent Veyron wrote:

> This is what I first did, using Apache::Session. But I noticed the call
> to tie was very slow (response time around 70ms with it, 15ms without
> it), so I changed for Storable because filesystem reads were much
> faster.

I don't personally like Apache::Session because of the tie thing, but
that's more an interface preference than anything else.

> Also, I did not find how to store a hash in the database without tie. I
> read it's possible to use Data::Dumper to write the data in a field and
> read it as Perl code. Would that be a way to do it?

The same way you're doing it now with Storable and a file. But instead
of reading a file you read a database field.

--
Michael Peters
Plus Three, LP


vv.lists at wanadoo

Jul 14, 2011, 12:15 PM

Post #7 of 14 (1362 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

Le jeudi 14 juillet 2011 à 13:02 -0400, Michael Peters a écrit :
> On 07/14/2011 12:57 PM, Vincent Veyron wrote:

> > Also, I did not find how to store a hash in the database without tie. I
> > read it's possible to use Data::Dumper to write the data in a field and
> > read it as Perl code. Would that be a way to do it?
>
> The same way you're doing it now with Storable and a file. But instead
> of reading a file you read a database field.
>

OK, I must have missed it in the doc, I'll look again.

Thank you

--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres et des contentieux pour le service juridique


perrin at elem

Jul 15, 2011, 2:59 PM

Post #8 of 14 (1345 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

On Thu, Jul 14, 2011 at 3:15 PM, Vincent Veyron <vv.lists [at] wanadoo> wrote:
> OK, I must have missed it in the doc, I'll look again.

I think you're misunderstand. Storable doesn't do this for you. The
idea is you could capture the session in a variable and write that to
a database.

If you'd rather not roll your own but you don't like the
Apache::Session API, look at other stuff on CPAN like CGI::Session.

- Perrin


vv.lists at wanadoo

Jul 16, 2011, 10:01 AM

Post #9 of 14 (1347 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

Le vendredi 15 juillet 2011 à 17:59 -0400, Perrin Harkins a écrit :

> I think you're misunderstand. Storable doesn't do this for you. The
> idea is you could capture the session in a variable and write that to
> a database.
>

Let me explain; I used to do :

tie %session, 'Apache::Session::Postgres', $session_id, {...};

and then

$r->pnotes('session' => \%session);

$session_id is taken from the cookie, %session stores several
parameters/variables.

As I said, I replaced the call to tie with :

$r->pnotes('session' => Storable::retrieve($session_file));

where $session_file again is retrieved from the cookie.

What I can't find out is : how do I store %session into a database
without using tie??


--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres et des contentieux pour le service juridique


perrin at elem

Jul 16, 2011, 6:06 PM

Post #10 of 14 (1342 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

On Sat, Jul 16, 2011 at 1:01 PM, Vincent Veyron <vv.lists [at] wanadoo> wrote:
> As I said, I replaced the call to tie with :
>
> $r->pnotes('session' => Storable::retrieve($session_file));
>
> where $session_file again is retrieved from the cookie.
>
> What I can't find out is : how do I store %session into a database
> without using tie??

That's what I'm trying to explain. You can either use the Storable
API to put your session into a string, and then write to a database
using standard DBI, or you can use a pre-built tool like CGI::Session.

To serialize your session to a string, you can do something like this:
use Storable qw(nfreeze);
$serialized = nfreeze \%session;

See the Storable docs for more.

- Perrin


pv2100 at gmail

Jul 16, 2011, 10:16 PM

Post #11 of 14 (1341 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

Back to Vincent's original request about session id and login: how secure is
your session id? Have you signed it? If not, someone can try to sending
random IDs and break your authentication.

Well, if you sign it and sign it properly, you basically end up with the
same idea in those "Authen + Ticket + Gate" CPAN modules. Besides a time
stamp, you should also sign with user's IP. If the cookie is stolen, the
origin of IP may protect as the last hope.

(if you are using https, then all the above procedures do not matter)

The second idea is that you may not need to store session on the server at
all: if the information in the session is merely user information such as
user id, name, email etc., you can concatenate them into the cookie value
(again, sign it). So the next time the user visits, you automatically get
those information back from the cookie.

Cheers.


On Sat, Jul 16, 2011 at 6:06 PM, Perrin Harkins <perrin [at] elem> wrote:

> On Sat, Jul 16, 2011 at 1:01 PM, Vincent Veyron <vv.lists [at] wanadoo>
> wrote:
> > As I said, I replaced the call to tie with :
> >
> > $r->pnotes('session' => Storable::retrieve($session_file));
> >
> > where $session_file again is retrieved from the cookie.
> >
> > What I can't find out is : how do I store %session into a database
> > without using tie??
>
> That's what I'm trying to explain. You can either use the Storable
> API to put your session into a string, and then write to a database
> using standard DBI, or you can use a pre-built tool like CGI::Session.
>
> To serialize your session to a string, you can do something like this:
> use Storable qw(nfreeze);
> $serialized = nfreeze \%session;
>
> See the Storable docs for more.
>
> - Perrin
>


vv.lists at wanadoo

Jul 17, 2011, 2:12 AM

Post #12 of 14 (1337 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

Le samedi 16 juillet 2011 à 21:06 -0400, Perrin Harkins a écrit :
> On Sat, Jul 16, 2011 at 1:01 PM, Vincent Veyron <vv.lists [at] wanadoo> wrote:

> To serialize your session to a string, you can do something like this:
> use Storable qw(nfreeze);
> $serialized = nfreeze \%session;
>

I see the light!

Thanks a bunch for taking the time to explain.

--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres et des contentieux pour le service juridique


vv.lists at wanadoo

Jul 17, 2011, 3:37 AM

Post #13 of 14 (1334 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

Le samedi 16 juillet 2011 à 22:16 -0700, Phil Van a écrit :
> Back to Vincent's original request about session id and login:

> (if you are using https, then all the above procedures do not matter)
>

It's via https, yes.

> The second idea is that you may not need to store session on the
> server at all: if the information in the session is merely user
> information such as user id, name, email etc., you can concatenate
> them into the cookie value (again, sign it). So the next time the user
> visits, you automatically get those information back from the cookie.

I am trying to avoid this, actually : the cookie only holds the session
id for retrieval. The hash stored on the server holds various parameters
for the user's session.

Very convenient for customization. For instance, I'm using it to store
field headers, which the client can then set to his liking.

--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres et des contentieux pour le service juridique


adam.prime at utoronto

Jul 17, 2011, 6:21 AM

Post #14 of 14 (1328 views)
Permalink
Re: Authentication logic [was: Changing browser URL based on condition] [In reply to]

On 7/17/2011 1:16 AM, Phil Van wrote:
> Back to Vincent's original request about session id and login: how
> secure is your session id? Have you signed it? If not, someone can try
> to sending random IDs and break your authentication.
>
> Well, if you sign it and sign it properly, you basically end up with the
> same idea in those "Authen + Ticket + Gate" CPAN modules. Besides a time
> stamp, you should also sign with user's IP. If the cookie is stolen,
> the origin of IP may protect as the last hope.

Tying a session to an IP can be bad if you use a CDN, or you have
clients that are behind big multihomed transparent proxies. AOL users
in particular used to come from various IP's during a single session.

Adam

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.