| line | stmt | bran | cond | sub | pod | time | code | 
| 1 |  |  |  |  |  |  | package Catalyst::Plugin::RapidApp::AuthCore::PlugHook; | 
| 2 | 1 |  |  | 1 |  | 1222 | use Moose::Role; | 
|  | 1 |  |  |  |  | 3 |  | 
|  | 1 |  |  |  |  | 7 |  | 
| 3 | 1 |  |  | 1 |  | 4538 | use namespace::autoclean; | 
|  | 1 |  |  |  |  | 2 |  | 
|  | 1 |  |  |  |  | 9 |  | 
| 4 |  |  |  |  |  |  |  | 
| 5 | 1 |  |  | 1 |  | 85 | use RapidApp::Util qw(:all); | 
|  | 1 |  |  |  |  | 3 |  | 
|  | 1 |  |  |  |  | 633 |  | 
| 6 |  |  |  |  |  |  |  | 
| 7 |  |  |  |  |  |  | =pod | 
| 8 |  |  |  |  |  |  |  | 
| 9 |  |  |  |  |  |  | =head1 DESCRIPTION | 
| 10 |  |  |  |  |  |  |  | 
| 11 |  |  |  |  |  |  | Plugin class seprated out of Catalyst::Plugin::RapidApp::AuthCore so | 
| 12 |  |  |  |  |  |  | it can be loaded as a *plugin* (not a role) **AFTER** the other | 
| 13 |  |  |  |  |  |  | required Authentication and Session plugins. This is needed to overcome | 
| 14 |  |  |  |  |  |  | load ordering issues. 'finalize_session' below doesn't exist until | 
| 15 |  |  |  |  |  |  | these plugins are loaded, and since AuthCore handles loading them, it | 
| 16 |  |  |  |  |  |  | can't also define the around (chickin/egg issue) | 
| 17 |  |  |  |  |  |  |  | 
| 18 |  |  |  |  |  |  | =cut | 
| 19 |  |  |  |  |  |  |  | 
| 20 |  |  |  |  |  |  |  | 
| 21 |  |  |  |  |  |  | # ---- FIXME  FIXME  FIXME (2013-08-25 by HV) ---- | 
| 22 |  |  |  |  |  |  | # | 
| 23 |  |  |  |  |  |  | # The sole purpose of this class is to make session extending (expires) | 
| 24 |  |  |  |  |  |  | # work. This is supposed to happen automatically, and does if the Auth/Session | 
| 25 |  |  |  |  |  |  | # plugins are loaded in the manner intended in the main app class: | 
| 26 |  |  |  |  |  |  | # | 
| 27 |  |  |  |  |  |  | #   use Catalyst qw( | 
| 28 |  |  |  |  |  |  | #     Authentication | 
| 29 |  |  |  |  |  |  | #     Authorization::Roles | 
| 30 |  |  |  |  |  |  | #     Session | 
| 31 |  |  |  |  |  |  | #     Session::State::Cookie | 
| 32 |  |  |  |  |  |  | #     Session::Store::DBIC | 
| 33 |  |  |  |  |  |  | #   ); | 
| 34 |  |  |  |  |  |  | # | 
| 35 |  |  |  |  |  |  | # Or later in: | 
| 36 |  |  |  |  |  |  | # | 
| 37 |  |  |  |  |  |  | #   __PACKAGE__->setup(qw( | 
| 38 |  |  |  |  |  |  | #     Authentication | 
| 39 |  |  |  |  |  |  | #     Authorization::Roles | 
| 40 |  |  |  |  |  |  | #     Session | 
| 41 |  |  |  |  |  |  | #     Session::State::Cookie | 
| 42 |  |  |  |  |  |  | #     Session::Store::DBIC | 
| 43 |  |  |  |  |  |  | #   )); | 
| 44 |  |  |  |  |  |  | # | 
| 45 |  |  |  |  |  |  | # However, for RapidApp, we obviously don't want the end developer to have to do | 
| 46 |  |  |  |  |  |  | # that. We want them to just do: | 
| 47 |  |  |  |  |  |  | # | 
| 48 |  |  |  |  |  |  | #   with 'Catalyst::Plugin::RapidApp::AuthCore'; | 
| 49 |  |  |  |  |  |  | # | 
| 50 |  |  |  |  |  |  | # and have it handle loading these plugins... This has been a struggle to | 
| 51 |  |  |  |  |  |  | # get to work right. AuthCore handles loading the plugins 'before' | 
| 52 |  |  |  |  |  |  | # $c->setup_dispatcher() because that is what is called immediately after | 
| 53 |  |  |  |  |  |  | # $c->setup_plugins() in Catalyst.pm, and so it should be the earliest | 
| 54 |  |  |  |  |  |  | # place to do it and have it work the same if AuthCore is loaded as a role | 
| 55 |  |  |  |  |  |  | # using 'with' or loaded using the older use Catalyst @plg/__PACKAGE__->setup(@plg) | 
| 56 |  |  |  |  |  |  | # syntax... (since everything before that point is before the plugin is loaded). | 
| 57 |  |  |  |  |  |  | # | 
| 58 |  |  |  |  |  |  | # It is not that I want to load it at this point, it is just that this is the | 
| 59 |  |  |  |  |  |  | # best point I have found to do it -- Is there some totally different place | 
| 60 |  |  |  |  |  |  | # or way to do this? | 
| 61 |  |  |  |  |  |  | # | 
| 62 |  |  |  |  |  |  | # It seems to work... ***almost***  ... Something is not quite right with the | 
| 63 |  |  |  |  |  |  | # resulting state, the example being the broken extending of sessions which I | 
| 64 |  |  |  |  |  |  | # am manually addressing below. Everything else seems to work and I don't know | 
| 65 |  |  |  |  |  |  | # why or where or how things end up different. I have tried lots of other | 
| 66 |  |  |  |  |  |  | # hook locations, like overriding '$c->arguments' and manually pushing the | 
| 67 |  |  |  |  |  |  | # plugin list into it, (which works only for loading using 'with', but it is | 
| 68 |  |  |  |  |  |  | # still broken in the same way). | 
| 69 |  |  |  |  |  |  |  | 
| 70 |  |  |  |  |  |  | # I don't understand the problem. It appears that certain methods just don't | 
| 71 |  |  |  |  |  |  | # exist and/or don't get called. I've dumped mro::get_linear_isa($c) and it | 
| 72 |  |  |  |  |  |  | # appears to come out the same, so I don't understand why that would be. I | 
| 73 |  |  |  |  |  |  | # still don't fully undertand all the mro/MI/setup that works under the hood, | 
| 74 |  |  |  |  |  |  | # and I think that is what is keeping me from figuring things out. | 
| 75 |  |  |  |  |  |  | # | 
| 76 |  |  |  |  |  |  | # Here is an example of my lack of understanding, and what I think is related | 
| 77 |  |  |  |  |  |  | # to the problem: | 
| 78 |  |  |  |  |  |  | # | 
| 79 |  |  |  |  |  |  | # If I try to use a normal sub with next::method, instead of 'around' below, | 
| 80 |  |  |  |  |  |  | # this gets thrown: | 
| 81 |  |  |  |  |  |  | #  Caught exception in engine "No next::method 'finalize_session' found for ... | 
| 82 |  |  |  |  |  |  | # | 
| 83 |  |  |  |  |  |  | # Could it have to do with mixing method overrides with around and next::method | 
| 84 |  |  |  |  |  |  | # style? It looks like the point where it might break, in following the Auth/Session | 
| 85 |  |  |  |  |  |  | # plugins code, which seem to point back and forth at eachother in a maze, is that many | 
| 86 |  |  |  |  |  |  | # methods, such as 'extend_session_id', return with maybe::next::method, which | 
| 87 |  |  |  |  |  |  | # might explain the silently broken functionality, but still not *why* that is... | 
| 88 |  |  |  |  |  |  | # | 
| 89 |  |  |  |  |  |  | # I am putting this on the shelf for now, since I have a workaround below for this | 
| 90 |  |  |  |  |  |  | # particular problem, but I am very concerned that my lack of understanding of these | 
| 91 |  |  |  |  |  |  | # internals could be leading to other, deep, dark broken things that just haven't | 
| 92 |  |  |  |  |  |  | # been noticed... | 
| 93 |  |  |  |  |  |  |  | 
| 94 |  |  |  |  |  |  | around 'finalize_session' => sub { | 
| 95 |  |  |  |  |  |  | my $orig = shift; | 
| 96 |  |  |  |  |  |  | my $c = shift; | 
| 97 |  |  |  |  |  |  |  | 
| 98 |  |  |  |  |  |  | if($c->_user) { | 
| 99 |  |  |  |  |  |  | my $expires = $c->session_expires; | 
| 100 |  |  |  |  |  |  | my $sid = $c->sessionid; | 
| 101 |  |  |  |  |  |  | $c->store_session_data( "expires:$sid" => $expires ); | 
| 102 |  |  |  |  |  |  | } | 
| 103 |  |  |  |  |  |  |  | 
| 104 |  |  |  |  |  |  | $c->$orig(@_); | 
| 105 |  |  |  |  |  |  | }; | 
| 106 |  |  |  |  |  |  |  | 
| 107 |  |  |  |  |  |  | 1; | 
| 108 |  |  |  |  |  |  |  |