| # |
Oct 6th 2016, 16:41 |
 nemmons |
Unfortunately that's not working. I believe it's because it's the job of the FootprintAwareTrait to attach the FootprintListener to the table, so just adding the behavior in the beforeFilter isn't enough. But this gives me an avenue to explore so i appreciate you pointing me in the right direction |
| # |
Oct 6th 2016, 16:25 |
hmic |
let me know how its going |
| # |
Oct 6th 2016, 16:25 |
hmic |
beforeFilter *callback*, not *event* is late enough in the process to have the user authenticated already *imho* - just debug($this->Auth->user()) from there to verify. |
| # |
Oct 6th 2016, 16:24 |
hmic |
my idea - not tested - basically: AppController::beforeFilter() { TableRegistry->get('User')->attachBehavior('Footprint'); } |
| # |
Oct 6th 2016, 16:23 |
hmic |
if not, just use beforeFilter (callback!) to attach it |
| # |
Oct 6th 2016, 16:23 |
nemmons |
Okay, that all makes sense, thank you. |
| # |
Oct 6th 2016, 16:23 |
hmic |
there does even exist a proper event in the auth class, afterAuthenticate, i think |
| # |
Oct 6th 2016, 16:23 |
hmic |
hint: you can get the usertable from the tableregistry and manually attach the footprint behavior after the user has been authenticated |
| # |
Oct 6th 2016, 16:22 |
hmic |
you need to table to authenticate the user, so you cannot attach it to this table (in one go) - ever. |
| # |
Oct 6th 2016, 16:22 |
hmic |
easy answer: before the logged in user is not known, you cannot attach footprint to the talbe |
| # |
Oct 6th 2016, 16:20 |
nemmons |
@hmic oh, i see. I guess i don't understand the code base well enough yet to see how beforeFilter is relevant to my question. I'll keep reading. |
| # |
Oct 6th 2016, 16:18 |
hmic |
still: even though this is a mess, it has for sure not been changed since 3.0, so not since may - 2015! |
| # |
Oct 6th 2016, 16:18 |
hmic |
which are run on completely different times |
| # |
Oct 6th 2016, 16:17 |
hmic |
nemmons: i am talking about the beforeFilter callback and event |
| # |
Oct 6th 2016, 16:17 |
nemmons |
@hmic Thank you but I'm sorry, I'm not sure i understand what you mean here. $controller->startupProcess is called which dispatches the Controller.initialize and Controller.startup events, After the controller action is invoked, $controller->render is called which dispatches the beforeRender event. |
| # |
Oct 6th 2016, 16:16 |
hmic |
the solution to your problem is using an iframe and echoing the html in there - you might need to utilize js to get this done easily. |
| # |
Oct 6th 2016, 16:15 |
hmic |
julez, so you echoed it out already? - yes this breakes the whole thing. as you have a complete <html> page in there. this is one of the reasons i said you might want to only render the element. |
| # |
Oct 6th 2016, 16:14 |
hmic |
i am quite sure nothing in this sequence or names has changed since may. |
| # |
Oct 6th 2016, 16:14 |
hmic |
the controller starup sequence is quite a mess regarding the names of events and callbacks! |
| # |
Oct 6th 2016, 16:13 |
hmic |
nemmons: you need to distinguish between the callbacks and events |
| # |
Oct 6th 2016, 16:13 |
nemmons |
(For background, Footprint is working great in my app in general but it's not working for my Users table. I think it's because UsersTable is initialized in AppController::initialize but i'm trying to prove that to myself and determine a workaround) |
| # |
Oct 6th 2016, 16:12 |
hmic |
passing it already? without you doing anything to it? whats in the logs? oom? |
| # |
Oct 6th 2016, 16:12 |
slackebot |
definitely called before Controller::beforeRender().. Is it possible this has changed since May when you said this, or am i horribly misreading this code? |
| # |
Oct 6th 2016, 16:12 |
nemmons |
@admad if you have a second i'm wondering if you could clarify a statement you made regarding a closed Muffin/Footprint issue (https://github.com/UseMuffin/Footprint/issues/13>).. I came across it while trying to debug a problem I had. "A table initialized in Controller::beforeRender() won't get the footprint since AuthComponent::startup() has still not run." Looking in Http/ActionDispatcher-_invoke() it looks to me like component startup me |
| # |
Oct 6th 2016, 16:10 |
hmic |
good luck! feel free to ask for help |
| # |
Oct 6th 2016, 16:04 |
hmic |
so as i said: basically replace the cake folder with the new one and give it a shot |
| # |
Oct 6th 2016, 16:04 |
hmic |
additionally this sentence, the first one of the migration guide: "CakePHP 2.5 is a fully API compatible upgrade from 2.4" |
| # |
Oct 6th 2016, 16:03 |
hmic |
just run your testsuite |
| # |
Oct 6th 2016, 16:02 |
hmic |
you should really give it a try and dont hide after the unknown codebase and size - and time constraits and so on :p |
| # |
Oct 6th 2016, 16:01 |
hmic |
as you can see, its quite good. it tells about things that have changed and are common pitfalls to look out for and about new things that might be handy too |
| # |
Oct 6th 2016, 16:01 |
hmic |
follow the things mentioned in there. then go on till you hit a problem |
| # |
Oct 6th 2016, 16:00 |
hmic |
thats it. you start with 2.4 -> 2.5 of course |
| # |
Oct 6th 2016, 16:00 |
hmic |
there is actually! |
| # |
Oct 6th 2016, 15:59 |
Neon1024 |
Hah |
| # |
Oct 6th 2016, 15:58 |
hmic |
if you want it upgraded faster, tell me the url, i'd see if a known security vulnarablity makes your decision makers want to upgrade it :p |
| # |
Oct 6th 2016, 15:57 |
hmic |
not that this would be enough :p but its far better then the 2.4 thing already |
| # |
Oct 6th 2016, 15:57 |
hmic |
upgrade to 2.6 should be a drop-in, really! |
| # |
Oct 6th 2016, 15:56 |
hmic |
2.6 should be just a drop-in upgrade. from there you might get the one or the other warning of things you need to fix actually |
| # |
Oct 6th 2016, 15:55 |
hmic |
upgrade! |
| # |
Oct 6th 2016, 15:54 |
hmic |
still: i'd just render the email element instead! |
| # |
Oct 6th 2016, 15:54 |
hmic |
just assign it to a viewvar to render in the view later! |