User Authorization in KohanaPHP App vs Endless Loop - redirect

Wondering how to name this question. Think this is the best situation possible.
Situation:
I got small app written in KohanaPHP framework. However there's one small bug that makes my crazy.
I got my own Core_Controller that is extended by every controller in this app. In constructor of this controller, I'm checking user profile status. So far so good. Although I'm facing a logical issue. It's called endless redirect loop. If I try to redirect (in Core_Controller constructor) user to Member_Controller it cannot be workig due to endless lopp. I understand why it happen.
Solution:
I'm looking for a solution how to make it flexible. I tried to move this verification to a helper and call it in Core_Controller constructor. However, it can be working correctly.
Question:
Do I have to put verification in constructor of every single controller? IS there any universal method to do it?
Waiting for your thoughts.
M.A.

Just check if user is verified and the current request's action isn't something like member/verification, do the redirect.
And parent::__construct(); will call the parent constructor, so I don't see the problem in that either..

You need a condition where it doesn't redirect (on the page you have redirected to). You'll want some code similar to this.
if not member_controller then
redirect to member_controller
else
do nothing
endif
The else isn't needed, but just added so it's more clear to you.

Related

How do relative URLs work in Sinatra?

I am hosting my Sinatra application using Apache with Passenger. It's hosted within a subfolder -- meaning, my main site is example.com, my application is at example.com/popcorn.
So I have a get '/' route, and that works fine. The problem is that my view includes a HTML form that makes a post request to upload, and the post '/upload' route isn't handling it. Instead of example.com/popcorn/upload, it's trying to get example.com/upload.
So I figure okay, not the ideal solution, but for now I'll hardcode the form action URL. But that doesn't work either -- making the action popcorn/upload fails too. This is where I get a little baffled, and my Google-fu was weak, I couldn't find help there.
Maybe I could have some kind of Apache rewrite rule, but is that the correct solution? Am I missing something? I would really appreciate a tip here because it feels like I've messed up something very simple and it's really bugging me.
You probably want the url helper method. That takes into account where the app is mounted on the server:
url('/upload')
The above code will evaluate to something like this:
http://example.com/popcord/upload
Inside your app you shouldn’t need to change anything, this will be routed to the existing post '/upload' handler.

Zend Sessions not stored for step3

I have used zend session as bellow..
$test = new Zend_Session_Namespace('test');
$test->test = "test text";
But when i move from one step to another step its working fine and echoes value Not on step3. even i tried using $_SESSION direct (because am desperate this to work ). But i have same problem that session not stored. Site seems almost broken when i use mozilla and IE. Not only in my PC But i have tested in multiple systems.
Tried clearing cookies, used cookie enabled browser only.
SO please suggest me what could be the posible problem in doing above. even i have inserted zend_session::start();
Thanks in advance,
Sanjeevk,
You haven't provided any useful code for what you are trying to accomplish, so I'm going to guess.
I have encountered a problem similar to this as well. My issue was simply trying to persist a page number from the paginator so I could perform an operation on a record and then return to the same page in the previous action.
The problem I was having was that the controller would overwrite the session data every time I called the action (page refresh), so while the page number would persist to other actions as soon as I called the original action the session would be over written and the page would reset to 1.
My solution was to get the page number from the view script and then feed it back to the controller later.
//the view script
<?php $session = new Zend_Session_Namespace('page'); $page = $this->paginator->getCurrentPageNumber(); ?>
so now when call $session->page anywhere in my controller/actions the data is still there and doesn't overwrite until the view is actually rendered, which is exactly what I needed.
You may be encountering something similar. Because of the way PHP and Zend Framework operate you may be inadvertently over writing your session data.
If this doesn't help, please provide more information and maybe an answer can be found.
Hope this provides some help or at least hints.

How to show previous url after user has canceled dialog with message from Activity#mayStop()?

In our app we need to check if the data is saved when we are in a particular place before navigating away from it. So the user should be able to negate a browser back button request. But by the time that the history value change event is received the url has already been changed. The History class doesn't seem to have a way to restore the url back. Anybody have any ideas?
In GWT 2.1 you get Activities and Places. And activity has a maystop method, which is exactly what you want, if I understand you correctly.
Use a window.onunload or window.onbeforeunload javascript callback to confrim/save state.
onbeforeunload example
I haven't actually implemented this behavior yet, but here is my plan and maybe it will work for you.
1) Each time you receive an onHistoryChanged event and decide to allow it, save the current historyToken in an instance variable somewhere.
2) Keep track of activity on the page that should block navigation. Use a data structure that can keep track of multiple activities, like multiple file uploads, multiple edits, etc.
3) When you receive a new onHistoryChanged event, if your data structure from #2 indicates that it's not safe to navigate, avoid changing the page and restore the historyToken that you saved in #1. I'm assuming that you can do this either by:
a) Calling History.newItem(oldHistoryToken, false) or
b) Calling History.newItem(oldHistoryToken, true) and keeping a flag to force the next onHistoryChanged to be ignored.
Again, I haven't actually implemented this so let me know how it works out.
If you have links that allow the user to leave the app and you want to prevent that as well, you'll need to also add an onbeforeunload.
Have a look at the PlaceManagerImpl class from the gwt-platform framework. Especially the onValueChange() method and the methods dealing with the onLeaveQuestion field.
Hope that helps.
In this issue report, t.broyer explains in his comment that such behavior was planned during design of Places framework. The most important part is:
mayStop was a mistake, or it should have only been called when unloading the app, not for internal navigation within the app.
So probably it's better to not use it at all...

ZEND plugin running twice. Why or how to simulate it?

Im hours and hours finding why one of my ZEND plugin sometimes running twice (depends on URL)
Note that my plugin has preDispatch and postDispatch methods and when I debugging the code it works like this:
MY_Plugin:preDispatch (echo $_SESSION['DBG'] has value)
MY_Plugin:postDispatch (unset($_SESSION['DBG']))
and then again
MY_Plugin:preDispatch (echo $_SESSION['DBG'] not exist)
MY_Plugin:postDispatch
This is part of bootstrap code
$_SESSION['DBG'] = 'value';
$MYrouter = new MY_Router_MyRouter();
$frontController->setRouter($MYrouter);
$frontController->registerPlugin(new MY_Plugin());
Do you have any suggestion how this could occur or how can I simulate this.
Thanks for any suggestion
Cervenak
Thanks guys for lot of valuable hints.
Now watch my story :)
First I had turned off showing exceptions (parameter False). So I switch them ON to see exception notification.
$frontController->throwExceptions(true);
Than I saw that I dont have uploaded controller and view files. After uploading them ZEND started to work corectly.
Good to know to have this direction set ON during debugging. You could probably save hours.
The dispatcher loop most likely running twice (the controller is dispatched twice). Possible causes:
using action view helper
calling _forward
redirector action helper
manually calling dispatch()
dispatch loop aborted and started again (eg. resetting request params)
Also, take a look at this ZF flow diagram (hotlinked from php-professionals.com)
Another reason could be an missing favicon.ico :-)
If the Apache cant find it, it fires a second request.

Periodically calling TinyMCE's triggerSave function

If anyone knows TinyMCE well, do you know if it has built-in support for periodically calling its triggerSave function?
(This function copies it's content to its "parent" textarea. I want to observe said textarea for changes so I can implement autosave.)
Thanks
Don't try autosave, trust me on this one. triggerSave is buggy and when it fails it fails silently so you think that your content got posted, but in reality it didn't. After it fails once it will no longer work for the rest of the session, as in until the page is manually reloaded and tinymce does another full init().
Just got bit by this one badly, again. Never again trust triggerSave.
You could easily do this yourself by using JavaScript's setTimeout() function.
See http://www.w3schools.com/js/js_timing.asp.