[Dancer-users] login example using before filter
Puneet Kishor
punk.kish at gmail.com
Sat Dec 4 14:30:26 CET 2010
Hi Joel,
I am doing my implementation a bit differently, so the following is all
guesswork, but I think you will find it useful. See below...
Joel Roth wrote:
> I've had some difficulties with the before filter example
> provided in Dancer::Introduction.
>
> If we pass the information via 'session' rather than 'var'
> and use 'redirect' instead of 'request->path_info'
> we get code that more-or-less works as expected:
>
> before sub {
> if (!session('user') and request->path_info !~ m{^/login}) {
> session requested_path => request->path_info;
> redirect('/login');
> }
> };
>
> post '/login' => sub {
> # authenticate credentials
> session user => params->{user};
> my $path = session->{requested_path};
> session requested_path => undef;
> redirect $path
> };
>
> Here is naive code based on the docs that _doesn't_ work:
>
> before sub {
> if (!session('user')&& request->path_info !~ m{^/login}) {
> var requested_path => request->path_info;
> request->path_info('/login');
> }
> };
>
> post '/login' => sub {
> # check credentials
> session user => params->{user};
> my $path = vars->{requested_path};
> redirect $path # [1]
> # request->path_info($path) # [2]
> };
>
> The first difference is that this 'before'
> filter causes the login page to show the original URL
> instead of /login.
Which it would. By changing requested path via
`request->path_info('/login')` you are changing the path internally. If
you want the URI in the browser to change as well, then you have to use
`redirect` which is equivalent to doing an http-refresh.
> The second difference is that neither of the rerouting
> alternatives leads to the desired behavior.
>
> [1] results in VOID.
> [2] results '/initial_requested_path' as display content
>
> I'd be interested in understanding how to fix the failed
> implementation.
>
The above also is expected. By the time you come to `post '/login'`, the
requested path is already /login.
Your working code above is correct. What you are doing is saving the
requested path in a session variable. That ensures that the value
persists over repeated calls. Then, you are redirecting, which emulates
a browser refresh, a brand new call to the server, this time requesting
the login page. Once at the login page, you extract the previously
requested path from the session var. All that makes sense, and works as
expected.
> And I'm also willing to patch the docs to show a complete,
> successful implementation.
I haven't looked at the latest docs. If you think the docs are
misleading, definitely file an issue with the suggested complete
documentation that works.
> Cheers,
>
> Joel
>
More information about the Dancer-users
mailing list