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

Mailing List Archive: Catalyst: Users

patch for C::P::Session::Store::Cookie

 

 

Catalyst users RSS feed   Index | Next | Previous | View Threaded


fayland at gmail

Jun 8, 2009, 11:26 PM

Post #1 of 6 (568 views)
Permalink
patch for C::P::Session::Store::Cookie

hey, it's a patch for Catalyst::Plugin::Session::Store::Cookie. to make
cookie_domain more configurable.

__PACKAGE__->config->{session}->{cookie_domain} = sub {
my $c = shift;
if ( $c->req->uri->host =~ /xxx\.com/ ) {
return '.xxx.com';
} else {
return '.yyy.com';
}
};

if it's acceptable, I'll provide a .t for that.

Thanks.
Attachments: configurable_cookie_domain.diff (1.40 KB)


bobtfish at bobtfish

Jun 9, 2009, 10:41 AM

Post #2 of 6 (530 views)
Permalink
Re: patch for C::P::Session::Store::Cookie [In reply to]

Fayland Lam wrote:
> hey, it's a patch for Catalyst::Plugin::Session::Store::Cookie. to make
> cookie_domain more configurable.
>
> __PACKAGE__->config->{session}->{cookie_domain} = sub {
> my $c = shift;
> if ( $c->req->uri->host =~ /xxx\.com/ ) {
> return '.xxx.com <http://xxx.com>';
> } else {
> return '.yyy.com <http://yyy.com>';
> }
> };
>
> if it's acceptable, I'll provide a .t for that.

Er, I don't see the value of putting code refs into config - that's
fairly insane.. Code != config.

What are you actually trying to achieve here (i.e. what are some example
use cases)?

But yes, patches to improve flexibility with tests would be generally
welcome.

Cheers
t0m




_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


jshirley at gmail

Jun 9, 2009, 11:19 AM

Post #3 of 6 (529 views)
Permalink
Re: patch for C::P::Session::Store::Cookie [In reply to]

On Tue, Jun 9, 2009 at 10:41 AM, Tomas Doran <bobtfish[at]bobtfish.net> wrote:

> Fayland Lam wrote:
>
>> hey, it's a patch for Catalyst::Plugin::Session::Store::Cookie. to make
>> cookie_domain more configurable.
>>
>> __PACKAGE__->config->{session}->{cookie_domain} = sub {
>> my $c = shift;
>> if ( $c->req->uri->host =~ /xxx\.com/ ) {
>> return '.xxx.com <http://xxx.com>';
>> } else {
>> return '.yyy.com <http://yyy.com>';
>> }
>> };
>>
>> if it's acceptable, I'll provide a .t for that.
>>
>
> Er, I don't see the value of putting code refs into config - that's fairly
> insane.. Code != config.
>
> What are you actually trying to achieve here (i.e. what are some example
> use cases)?
>
> But yes, patches to improve flexibility with tests would be generally
> welcome.
>
> Cheers
> t0m
>
>
>
I can't speak to the method, but the desire is something I would like to
have. If an application is accessible via different domains, it is nice to
be able to change the cookie name.

A simple, and contrived but real world example, is this:

Production application lives on secure.domainname.com, but shares auth
cookies with www.domainname.com

As such, you set cookie_domain => '.domainname.com'

However, in development without special modification (local config having
cookie_domain => 'localhost') you can't login anymore.

Being able to specify the session cookie name based on the request would be
useful for edge cases.

-J


bobtfish at bobtfish

Jun 9, 2009, 1:15 PM

Post #4 of 6 (530 views)
Permalink
Re: patch for C::P::Session::Store::Cookie [In reply to]

On 9 Jun 2009, at 19:19, J. Shirley wrote:
> Being able to specify the session cookie name based on the request
> would be useful for edge cases.

I totally agree.

How would something like a 'cookie_name_stash_key' configuration
parameter sit with you?

If not provided, we do what we do now, if provided then that stash
key will be used if present and defined, otherwise the default
handling will be used.

Cheers
t0m


_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


jshirley at gmail

Jun 9, 2009, 1:29 PM

Post #5 of 6 (523 views)
Permalink
Re: patch for C::P::Session::Store::Cookie [In reply to]

On Tue, Jun 9, 2009 at 1:15 PM, Tomas Doran <bobtfish[at]bobtfish.net> wrote:

>
> On 9 Jun 2009, at 19:19, J. Shirley wrote:
>
>> Being able to specify the session cookie name based on the request would
>> be useful for edge cases.
>>
>
> I totally agree.
>
> How would something like a 'cookie_name_stash_key' configuration parameter
> sit with you?
>
> If not provided, we do what we do now, if provided then that stash key will
> be used if present and defined, otherwise the default handling will be used.
>
>
If it can understand nested keys in the stash, I'm all in favor of it.

Something like $c->stash->{page}->{cookie_domain} would fit inline with what
I currently do for similar things.

-J


bobtfish at bobtfish

Jun 9, 2009, 1:42 PM

Post #6 of 6 (527 views)
Permalink
Re: patch for C::P::Session::Store::Cookie [In reply to]

On 9 Jun 2009, at 21:29, J. Shirley wrote:

> On Tue, Jun 9, 2009 at 1:15 PM, Tomas Doran <bobtfish[at]bobtfish.net>
> wrote:
>
> How would something like a 'cookie_name_stash_key' configuration
> parameter sit with you?
>
> If not provided, we do what we do now, if provided then that stash
> key will be used if present and defined, otherwise the default
> handling will be used.
>
> If it can understand nested keys in the stash, I'm all in favor of it.
>
> Something like $c->stash->{page}->{cookie_domain} would fit inline
> with what I currently do for similar things.

I guess if cookie_name_stash_key is a non ref scalar, then it's
treated as a sting ($c->stash->{$cookie_name_stash_key}), otherwise
it's treated as a set of keys (e.g. cookie_name_stash_key => [qw/page
cookie_domain/] does your example above.

Cheers
t0m

Catalyst users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.