FAQ
Hi,

Using (in some legacy code):

Catalyst-Controller-FormBuilder-0.05
Catalyst 5.80029

Getting lots of warnings for:

Catalyst::Controller::FormBuilder uses NEXT, which is deprecated. Please see the Class::C3::Adopt::NEXT documentation for details. NEXT used at ... /lib/Catalyst/Controller/FormBuilder.pm line 12

Patch attached.

Could someone apply/roll it out please?

Thanks,
Anthony Gladdish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Catalyst-Controller-FormBuilder.patch
Type: application/octet-stream
Size: 1072 bytes
Desc: Catalyst-Controller-FormBuilder.patch
Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110125/d2807c4b/Catalyst-Controller-FormBuilder.obj

Search Discussions

  • Ben van Staveren at Jan 26, 2011 at 10:17 am
    Hi folks, I've been breaking my head over this one for the last 3 hours and I
    can't figure out what the hell is going on. I'm using Catalyst::Authentication
    to deal with authentication, as follows:

    in Root.pm:

    sub auto {
    my $self = shift;
    my $c = shift;

    if(!$c->user_exists) {
    warn "user does not exist\n";
    $c->res->redirect('/login');
    return 0;
    }
    return 1;
    }

    sub index :Path Args(0) {
    my $self = shift;
    my $c = shift;
    $c->res->redirect('/dashboard/');
    }

    So far so good, but... when loading up without being logged in, this happens:

    user does not exist
    [info] *** Request 4 (0.037/s) [4201] [Wed Jan 26 17:07:35 2011] ***
    [debug] "GET" request for "/" from "127.0.0.1"
    [debug] Path is "/"
    [debug] Found sessionid "130f7df91fcd9ca31c59eaa9c24f52de63d0c185" in cookie
    [debug] Restored session "130f7df91fcd9ca31c59eaa9c24f52de63d0c185"
    [debug] Rendering template "index.tt2"
    [debug] Redirecting to "/dashboard/"

    Strangely enough, it seems that the c->res->redirect isn't taking for some
    reason, this used to work before, and suddenly stopped working. I've been
    trying to figure out what I've changed that would cause this, and I haven't
    touched any of the authentication bits at all.

    If I am in fact logged in, c->res->redirect works exactly as advertised and
    will happily do the trick, except in this case where I have not logged in.

    Any ideas? I'm about ready to shoot this project in the head :(
  • Denny at Jan 26, 2011 at 11:10 am

    On Wed, 2011-01-26 at 17:17 +0700, Ben van Staveren wrote:
    Hi folks, I've been breaking my head over this one for the last 3 hours and I
    can't figure out what the hell is going on. I'm using Catalyst::Authentication
    to deal with authentication, as follows:
    [...]
    Strangely enough, it seems that the c->res->redirect isn't taking for some
    reason, this used to work before, and suddenly stopped working. I've been
    trying to figure out what I've changed that would cause this, and I haven't
    touched any of the authentication bits at all.

    If I am in fact logged in, c->res->redirect works exactly as advertised and
    will happily do the trick, except in this case where I have not logged in.

    Any ideas? I'm about ready to shoot this project in the head :(
    Have you tried turning it off and then on again? ;)

    More seriously, I have found on multiple occasions that the Catalyst
    Auth stuff can seem to get itself into an inconsistent state, such that
    it starts behaving oddly (usually mine will successfully log in, but
    fail to keep track of that fact), and the only way to fix it is to
    delete the contents of the session store (database, in my case), delete
    all the cookies for the site, and possibly wipe the browser cache too.

    Other than that I'm not sure what to suggest. Where does the auto
    return to? Is it possible it's coming back from there to before the
    dashboard redirect, and so the redirect URL is getting overwritten
    before the output is constructed? (I've not used auto, so no idea if
    this is a stupid question or not.)

    Regards,
    Denny

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 490 bytes
    Desc: This is a digitally signed message part
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110126/38eb7951/attachment.pgp
  • Ben van Staveren at Jan 26, 2011 at 11:18 am
    Hi Denny & list,
    Have you tried turning it off and then on again? ;)
    Repeatedly :)
    More seriously, I have found on multiple occasions that the Catalyst
    Auth stuff can seem to get itself into an inconsistent state, such that
    it starts behaving oddly (usually mine will successfully log in, but
    fail to keep track of that fact), and the only way to fix it is to
    delete the contents of the session store (database, in my case), delete
    all the cookies for the site, and possibly wipe the browser cache too.

    Other than that I'm not sure what to suggest. Where does the auto
    return to? Is it possible it's coming back from there to before the
    dashboard redirect, and so the redirect URL is getting overwritten
    before the output is constructed? (I've not used auto, so no idea if
    this is a stupid question or not.)
    On the off-hand of being wrong, as far as I know, auto is called before
    anything else is really done, so your dispatch chain ends up going

    auto -> action -> end

    I think. Anyways, I did clear the session store, zapped all the cookies, and
    the behaviour's still there. I did some Data::Dumper action, and even after
    the RenderView action class had it's way with things, the status is still set
    to 302, a Location header is present in the output, but it did render the
    template that it's not supposed to render.

    Even if I do a "$c->detach('end') and return 0", it will render a template,
    which by all accounts, it's not supposed to be doing.

    Doing a telnet to the dev server and querying it does return the proper
    headers for a redirect as well; Status: 302 and Location: /login - but it also
    renders the output body, for some really freaky reason.

    The main issue for me is that this behaviour seems to be triggered by
    something I did in controller code somewhere, but I could swear up and down
    that I haven't done anything that touches even remotely near authentication or
    the Auth guts, so I'm totally and utterly stumped. And it's kind of important
    this works, deadlines and such things :(

    --

    Ben van Staveren
    phone: +62 81 70777529
    email: benvanstaveren@gmail.com
  • David Schmidt at Jan 26, 2011 at 12:48 pm

    On Wed, Jan 26, 2011 at 12:18 PM, Ben van Staveren wrote:
    Hi Denny & list,
    Have you tried turning it off and then on again? ?;)
    Repeatedly :)
    More seriously, I have found on multiple occasions that the Catalyst
    Auth stuff can seem to get itself into an inconsistent state, such that
    it starts behaving oddly (usually mine will successfully log in, but
    fail to keep track of that fact), and the only way to fix it is to
    delete the contents of the session store (database, in my case), delete
    all the cookies for the site, and possibly wipe the browser cache too.

    Other than that I'm not sure what to suggest. ?Where does the auto
    return to? ?Is it possible it's coming back from there to before the
    dashboard redirect, and so the redirect URL is getting overwritten
    before the output is constructed? ?(I've not used auto, so no idea if
    this is a stupid question or not.)
    On the off-hand of being wrong, as far as I know, auto is called before
    anything else is really done, so your dispatch chain ends up going

    auto -> action -> end

    I think. Anyways, I did clear the session store, zapped all the cookies, and
    the behaviour's still there. I did some Data::Dumper action, and even after
    the RenderView action class had it's way with things, the status is still
    set to 302, a Location header is present in the output, but it did render
    the template that it's not supposed to render.

    Even if I do a "$c->detach('end') and return 0", it will render a template,
    which by all accounts, it's not supposed to be doing.

    Doing a telnet to the dev server and querying it does return the proper
    headers for a redirect as well; Status: 302 and Location: /login - but it
    also renders the output body, for some really freaky reason.

    The main issue for me is that this behaviour seems to be triggered by
    something I did in controller code somewhere, but I could swear up and down
    that I haven't done anything that touches even remotely near authentication
    or the Auth guts, so I'm totally and utterly stumped. And it's kind of
    important this works, deadlines and such things :(

    --

    Ben van Staveren
    phone: +62 81 70777529
    email: benvanstaveren@gmail.com


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


    If all you want to do is redirecting the user to /login if he isn't
    logged in you could try CatalystX::SimpleLogin.
    Using auto for that stuff is kinda deprecated according to what I
    overheard in the irc channel.

    I couldn't find an error in what little information you have provided.
    I'd probably go and

    -) check if all relevant modules are up to date.
    -) try with a different browser
    -) create a simple app and try this particular code there.

    david
  • Octavian Rasnita at Jan 26, 2011 at 1:06 pm
    From: "David Schmidt" <davewood@gmx.at>
    On Wed, Jan 26, 2011 at 12:18 PM, Ben van Staveren
    wrote:
    Hi Denny & list,
    Have you tried turning it off and then on again? ;)
    Repeatedly :)
    More seriously, I have found on multiple occasions that the Catalyst
    Auth stuff can seem to get itself into an inconsistent state, such that
    it starts behaving oddly (usually mine will successfully log in, but
    fail to keep track of that fact), and the only way to fix it is to
    delete the contents of the session store (database, in my case), delete
    all the cookies for the site, and possibly wipe the browser cache too.

    Other than that I'm not sure what to suggest. Where does the auto
    return to? Is it possible it's coming back from there to before the
    dashboard redirect, and so the redirect URL is getting overwritten
    before the output is constructed? (I've not used auto, so no idea if
    this is a stupid question or not.)
    On the off-hand of being wrong, as far as I know, auto is called before
    anything else is really done, so your dispatch chain ends up going

    auto -> action -> end

    I think. Anyways, I did clear the session store, zapped all the cookies,
    and
    the behaviour's still there. I did some Data::Dumper action, and even
    after
    the RenderView action class had it's way with things, the status is still
    set to 302, a Location header is present in the output, but it did render
    the template that it's not supposed to render.

    Even if I do a "$c->detach('end') and return 0", it will render a
    template,
    which by all accounts, it's not supposed to be doing.

    Doing a telnet to the dev server and querying it does return the proper
    headers for a redirect as well; Status: 302 and Location: /login - but it
    also renders the output body, for some really freaky reason.

    The main issue for me is that this behaviour seems to be triggered by
    something I did in controller code somewhere, but I could swear up and
    down
    that I haven't done anything that touches even remotely near
    authentication
    or the Auth guts, so I'm totally and utterly stumped. And it's kind of
    important this works, deadlines and such things :(

    If all you want to do is redirecting the user to /login if he isn't
    logged in you could try CatalystX::SimpleLogin.
    Using auto for that stuff is kinda deprecated according to what I
    overheard in the irc channel.


    I thought that CatalystX::SimpleLogin can be used only in those apps that
    use HTML::FormHandler.
    What's the recommended way for the apps that use HTML::FormFu if using the
    auto private methods is deprecated?

    Thanks.

    Octavian
  • Ben van Staveren at Jan 26, 2011 at 1:15 pm

    -) check if all relevant modules are up to date.
    -) try with a different browser
    -) create a simple app and try this particular code there.
    I would do this if it wasn't for the fact that this code has worked just fine
    for the past year, and I haven't done any updates or upgrades for the last 2
    weeks. And the problem is, if this is something that is due to C::A getting
    it's knickers in a twist, that's a showstopper for me because I can't go and
    tell my end-users "yeah just clear your cache and try another browser", they'd
    lynch me on the spot.

    I'll give it another shot, see what happens.

    --
    Ben van Staveren
    phone: +62 81 70777529
    email: benvanstaveren@gmail.com
  • Charlie Garrison at Jan 26, 2011 at 11:04 pm
    Good morning,

    On 26/01/11 at 8:15 PM +0700, Ben van Staveren
    wrote:
    -) check if all relevant modules are up to date.
    -) try with a different browser
    -) create a simple app and try this particular code there.
    I would do this if it wasn't for the fact that this code has
    worked just fine for the past year, and I haven't done any
    updates or upgrades for the last 2 weeks. And the problem is,
    if this is something that is due to C::A getting it's knickers
    in a twist, that's a showstopper for me because I can't go and
    tell my end-users "yeah just clear your cache and try another
    browser", they'd lynch me on the spot.

    I'll give it another shot, see what happens.
    Did you update Catalyst-Action-RenderView, maybe you're running
    into one of these:

    0.16 2011-01-05 19:28:00 GMT
    - Fix bug accidentally introduced in the last version with response
    3xx statuses.

    0.15 2011-01-04 14:19:36 CET
    - Don't delegate to a view if the response body is set to `undef'.


    Charlie

    --
    ? Charlie Garrison ? <garrison@zeta.org.au>

    O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
    ? http://www.ietf.org/rfc/rfc1855.txt
  • Ben van Staveren at Jan 26, 2011 at 11:22 pm
    *groan* that would've been the culprit.
    - Fix bug accidentally introduced in the last version with response
    3xx statuses.

    0.15 2011-01-04 14:19:36 CET
    - Don't delegate to a view if the response body is set to `undef'.
    --
    Ben van Staveren
    phone: +62 81 70777529
    email: benvanstaveren@gmail.com
  • Tomas Doran at Jan 26, 2011 at 10:43 am

    On 25 Jan 2011, at 15:43, Anthony Gladdish wrote:
    Could someone apply/roll it out please?
    Applied, dist rolled.

    http://goatse.co.uk/~bobtfish/Catalyst-Controller-FormBuilder-0.06.tar.gz

    Should get shipped in the next 24 hours hopefully (I don't have the
    permissions to do so personally).

    Cheers
    t0m

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJan 25, '11 at 3:43p
activeJan 26, '11 at 11:22p
posts10
users7
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase