[Catalyst] New Auth/Session Stuff

[Christopher H. Laco]

Yuval Kogman wrote:
> On Wed, Nov 30, 2005 at 08:55:03 -0500, Christopher H. Laco wrote:
>> Everything Just Worked. Bravo to everyone involved. I spent more time
>> installing PREREQS than I did getting login/logout auth+session into my
>> Catalyst app. That's a very very good thing.
> 
> Woot!
> 
>> Now, on to the questions! :-)
>>
>> First, after I call $c->login(id, pass), I have a user hash object and
>> on further requests, it comes from the session.
>>
>> Just out of curiosity under TT, [% c.user.id %] returns nothing but
>> [% c.user.password %] returns the password. Is this a bug?
> 
> User::Hash has no ID unless you put it in.

Hmmmm..it supposedly has an id method I thought?
http://search.cpan.org/~nuffin/Catalyst-Plugin-Authentication-0.02/lib/Catalyst/Plugin/Authentication/User/Hash.pm#METHODS

Or, the user object returned:
http://search.cpan.org/~nuffin/Catalyst-Plugin-Authentication-0.02/lib/Catalyst/Plugin/Authentication/User.pm

id

    A unique ID by which a user can be retrieved from the store.



> 
> Look at the live_app_session.t test in C::P::Authentication - this
> is a hack to make User::Hash *use* ids by force.
> 
> This is because User::Hash's role is to actually provide a framework
> for potentially store-less authentication (e.g. TypeKey) to build
> on.
> 
> The reason it works this way with Store::Minimal is because that's
> obviously for testing and quickstarting. I can make it "safer" but I
> see no gain. With real stores the session contains a pointer to the
> user instead of the user itself, and things are more complicated but
> also safer.

That makes sense. Good to know. :-)


> 
>> Second, is there any reason why the password needs to be stored in the
>> session information? That seems like a dangerous and unnecessary thing
>> by default. If one needs the password, the should be able to get it from
>> get_user instead. I would think it's somewhat safer to rely on the Store
>> for passwords, and not have them floating around the session stores,
>> Maybe that depends on the store.
> 
> The session is safe - session data never gets into the client. At
> least arguably that's what should happen.

Semi safe. Someone just needs to hijack the session cookie value for
simple States...for more complicated ones, I'm there there is some
hashing/salting and/or browser string/ip matching to make that hijacking
harder.

> 
> Again, this is just for User::Hash. See 'sub for_session' in that
> class - it just returns '$self'. Most user classes would return
> '$self->id'.
> 
> User::Htpasswd, for example, stores
> 
> 	__user_store => "store_name", # probably "default"
> 	__user => "name",
> 
> and lazily does get_user when you call $c->user.
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20051130/8daeec04/smime-0001.bin