Re: Authentication logic [was: Changing browser URL based on condition]
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
Re: Authentication logic [was: Changing browser URL based on condition]
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
Re: Authentication logic [was: Changing browser URL based on condition]
Le samedi 16 juillet 2011 à 21:06 -0400, Perrin Harkins a écrit : > On Sat, Jul 16, 2011 at 1:01 PM, Vincent Veyron 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
Re: Authentication logic [was: Changing browser URL based on condition]
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 wrote:
> On Sat, Jul 16, 2011 at 1:01 PM, Vincent Veyron
> 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
>
Re: Authentication logic [was: Changing browser URL based on condition]
On Sat, Jul 16, 2011 at 1:01 PM, Vincent Veyron 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
Re: Authentication logic [was: Changing browser URL based on condition]
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
Re: Authentication logic [was: Changing browser URL based on condition]
On Thu, Jul 14, 2011 at 3:15 PM, Vincent Veyron 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
Re: Authentication logic [was: Changing browser URL based on condition]
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
Re: Authentication logic [was: Changing browser URL based on condition]
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
Re: Authentication logic [was: Changing browser URL based on condition]
Le jeudi 14 juillet 2011 à 11:34 -0400, Perrin Harkins a écrit : > On Thu, Jul 14, 2011 at 11:21 AM, Vincent Veyron 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
Re: Authentication logic [was: Changing browser URL based on condition]
On Thu, Jul 14, 2011 at 11:21 AM, Vincent Veyron 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
Re: Authentication logic [was: Changing browser URL based on condition]
Le mercredi 13 juillet 2011 à 13:19 -0400, Perrin Harkins a écrit : > On Tue, Jul 12, 2011 at 8:45 AM, Vincent Veyron 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
Re: Authentication logic [was: Changing browser URL based on condition]
On Tue, Jul 12, 2011 at 8:45 AM, Vincent Veyron 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
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
