[Dancer-users] multiple layouts and login

[P Kishor]

On Wed, Aug 4, 2010 at 4:31 AM, David Precious <davidp at preshweb.co.uk> wrote:
> On Wednesday 04 August 2010 04:00:37 P Kishor wrote:
>> Hi,
>>
>> Is it possible to use different layouts for different parts of the
>> application, perhaps, for different routes? Right now, it seems, only
>> one layout per application is possible via the layout setting in the
>> config file.
>
> When calling template, you can optionally specify the layout to use via the
> third param, e.g.:
>
>  template 'page.tt' => { foo => 'bar'}, { layout => 'otherlayout.tt' };
>
> You could probably also manage it by updating the layout setting from a before
> handler, if you want it controlled in one place:
>
> before sub {
>    given (request->path) {
>        when (m{^/area1}) { layout 'area1.tt'; }
>        when (m{^/area2}) { layout 'area2.tt'; }
>        default           { layout 'main.tt';  }
>    }
> }


Great! both of the above answers should be in the cookbook/docs.

>
>> Also, I am looking for a tutorial (cookbook recipe, perhaps) on how to
>> create an authentication mechanism, one that would let me specify a
>> bunch of routes that should be available only after login, redirecting
>> the user to a login page.
>
> The cookbook itself contains such an example:
>
> http://search.cpan.org/dist/Dancer/lib/Dancer/Cookbook.pod#Sessions_and_logging_in
>
> Basically, use a before handler to check whether the user is logged in yet; if
> not, and they're requesting a page other than the login page, send them to the
> login page instead.


Actually, I did see that. My question arose from the need to "set"
certain routes as being available only after logging in, and being
able to do that in one place. Now, your answer above to my layouts
question has given me the idea that I can apply the same tactic for
logging in also. Would something like below work?

before sub {
   given (request->path) {
       when (m{^/area1|^/area2|^/district9}) { request->path_info('/login'); }
   }
}

btw, what is the difference between request->.. and redirect->.., I
mean, in effect, what is the difference? I am guessing the first one
will internally "redirect" keeping all the request params intact,
while the latter will redirect as if it were a new request, thereby
losing all the request params, no?


>
> At some point I'd like to write a few Dancer::Plugin::Auth modules to make
> this even easier; for instance, I could write one which uses PAM to
> authenticate real system users, so you could just 'use
> Dancer::Plugin::Auth::PAM', and anyone with a real user account on the machine
> hosting the app could log in easily.  Similarly, D::P::Auth::IMAP and
> D::P::Auth::LDAP could be useful too.
>
>
> Cheers
>
> Dave P
>
> --
> David Precious <davidp at preshweb.co.uk>
> http://blog.preshweb.co.uk/    www.preshweb.co.uk/twitter
> www.preshweb.co.uk/linkedin    www.preshweb.co.uk/facebook
> www.preshweb.co.uk/identica    www.lyricsbadger.co.uk
>
>  "Programming is like sex. One mistake and you have to support
>  it for the rest of your life". (Michael Sinz)
>



-- 
Puneet Kishor http://www.punkish.org
Carbon Model http://carbonmodel.org
Charter Member, Open Source Geospatial Foundation http://www.osgeo.org
Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor
Nelson Institute, UW-Madison http://www.nelson.wisc.edu
-----------------------------------------------------------------------
Assertions are politics; backing up assertions with evidence is science
=======================================================================