Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'd just check $c->action (or $c->action->reverse) instead of the path, in case you reconfigure it one day to another path. The rest is very nice :)

    --
    Ordinary morality is for ordinary people. -- Aleister Crowley
  • personal I do something like in sub end

    if ( $c->res->location ) {
    if ( $c->res->location eq '/login' ) {
    $c->flash->{path} = $c->req->uri->as_string;
    }
    }

    so that you don't need write session every request.
  • Just have the logout action accept a returnto query parameter, and stick the value of $c->req->uri into that when you emit the logout link. Much simpler; the server doesn’t have to do any bookkeeping, no DB accesses, nothing.

    Also, flash is bad anyway – subject to race conditions. It will restore the flashed variables into the session for whichever request happens to come in with the right session cookie, even if that request was made by a different tab/browser window/computer/scraper threa

    • I usually do something similar if I want to go to some other page after login/logout, but you don't need to prepopulate the login/logout links just use the REFERER header.

      • The referer is rather unreliable and can be, and is often, changed by the browser or a proxy.

        --
        Ordinary morality is for ordinary people. -- Aleister Crowley
    • Agreed.  In any event, flash-based solutions are unlikely to win you friends who are truly security conscious when there are static methods that have worked forever that still work.  (And, for that matter, shockwave, java, or javascript solutions will also not motivate friends in the above mentioned crowd.)

      Passing the information as form values is especially a good idea because it then makes passing other form values a no brainer.  And when you do that, the login form no longer causes your us

      • Err, “flash” in this case does not refer to Macromedia Flash, rather, to a particular feature of the session plugin.

        • Sigh.  That's what happens when I try to comment on things while trying to catch up on my reading.  If it had been using Macromedia Flash, then it wouldn't be storing the data server-side.

          However, I do think my point still stands of this mentality tends to drops post form data.  It doesn't have to - one could store that in session data also, but it's considerably easier and less problematic to simply use forms, as indicated for the more general case in your original response.

  • It seems like you got what flash and stash are backwards, from the docs in the Session plugin. You say flash lasts for one request. This is what the doc for it says:

    "Think of it as a stash that lasts for longer than one request, letting you redirect instead of forward."

    Am I misunderstanding?

    --
    --fREW
    http://blog.afoolishmanifesto.com
    • The stash lasts for the duration of a single request.

      The flash persists after the request and becomes part of the stash in the next request – but only once (unless you persist the data again).

      The terminology is kinda confusing, I guess.

      • Actually, it's not quite "persist the data again". Flash is only preserved if the data changes. Thus, if you need to preserve the same data across multiple requests, you need to use the keep_flash() method.