I could find the below way to include JavaScript in the application,
in file … plugins\Login\Login.php
public function getJsFiles(&$jsFiles)
{
$jsFiles[] = "plugins/Login/javascripts/login.js";
$jsFiles[] = "plugins/Login/javascripts/tests.js";
}
In this case, I manually (statically) add tests.js to login plugin which is executed when the login page is loaded. Is there a way to include javascript from controller based on the user role. Say, for example, the user is admin, so we need to include …plugins/Login/javascripts/admin.js from plugins\Login\Controller.phpdynamically?
Additionally, in Twig, is it possible to set view variable from another view?
For example,
I want to set a specific view variable for Feedback plugin from LoginController piwik\plugins\Login\Controller.php,
$view = new View('@Feedback/index');
$view->specialDataFromLogin = 'superuser';
without calling $view->render() method. Because, I would like to set a variable for Feedback Plugin from Login Plugin. Is it possible or is there any other way to set globally accessible variables from LoginController? If you need clarification in regards to this question, please POST, I will elaborate. I already searched all plugins and could not find this scenario except the piwik\core\View.php. Because, it’s very important to set twig variable in one plugin and call from another plugin so that development becomes damn easy.
Is there a way to include javascript from controller based on the user role.
No I don’t think so, your javascript will be always included.
Because, I would like to set a variable for Feedback Plugin from Login Plugin.
In the controller if you set the variable it should be accessible from all the view that are included in the view the controller is rendering. But you can’t set variables for other controller methods. Also it’s possible that the variable is overwritten somewhere along the inclusions. Maybe can you explain what you are trying to do?
This refers to the commit referred here: https://github.com/piwik/piwik/pull/7686 So, if the user has logged into the application and did not interact for more than 3 days. Then he is logged out of the site automatically. (For now, forget about users who have set "Remember my login") The code I prepared, do this in the given commit.
But Matthieu Aubry has pointed about one more scenario which wasn't covered in the fix. That is, if the loggedin user closes the browser or tab suddenly and comes back to site after 10 days or so, he would still be logged in. So, I have created another javascript file (let's call session monitor cookie) that sets a cookie to be valid for 3 days. This will be set only for logged in users. So, if this logged in user comes back after 3 or more days, he would be immediately logged out of the site either because of inactivity.
So, for this scenario, I am trying to set the twig view variable in [b]function authenticateAndRedirect($login, $password, $rememberMe, $urlToRedirect = false, $passwordHashed = false)[/b] in Login controller only for logged in user (not for any other users)
$view = new View('@CoreHome/getDefaultIndexView');
$this->setGeneralVariablesView($view);
$view->jsSpecialVariable = true;
So, I need to access this jsSpecialVariable from getDefaultIndexView.twig template because I could load the script only if the user is authenticated user.
For CoreHome plugin’s getDefaultIndexView template because the JavaScript file should only be loaded here as it’s the main template file for rendering. We could not set this twig variable to login plugin’s login.twig template because there is no point in setting here because these files (scripts loaded in this plugins) are immediately destroyed after redirection to Piwik’s admin pages.
The biggest advantage in this approach when compared with Aubry’s suggestion of server-side validation is that it’s fully done at client side and there is no HTTP round-trip to server. I hope you would guide me right.
I don’t see the point of implementing that to be honest.
The biggest advantage in this approach when compared with Aubry’s suggestion of server-side validation is that it’s fully done at client side and there is no HTTP round-trip to server.
You are not describing advantages, but only the technical details. What are really the advantages? We don’t see a problem with the existing server side solution. It’s also how it’s implemented everywhere else.
For this, the existing solution in other applications is like this: The application will make AJAX call to database about the user’s presence/activity every 8 or 10 (the time vary as per apps ) hour so that user’s last active time is stored in database. If the user closed the app without logging out and comes back after 1 or more days, the first thing that the application does is to make a call to check user’s last activity. In this case, the user’s timestamp is older than 1 day; in other words, the user didn’t log out the app properly. So he is redirected to login page.
In our case, if we implement the same and if we have 200K active users, there would be 200k or more AJAX requests to our server everyday. So, the advantage here is to avoid making HTTP request to server every 8 hour or so.
So, my idea is to update the user’s (idle session/improper log out) states only in client-side i.e cookies. Only when user reloads the page or open the page after unexpected page close, we check if the user session is valid or not and do appropriate actions. There is no periodical timestamp updates to server end and so no unwanted load on server. The solution should be more interesting and not at all expensive when compared with HTTP round trip calls.
For this, the existing solution in other applications is like this: The application will make AJAX call to database about the user’s presence/activity every 8 or 10 hour
Maybe some applications work that way but (as you said yourself) that’s not how Piwik works. So there is no point in avoiding a problem that we do not have.
The issue you linked to said:
If you click “Remember me” then you will be logged in forever. I think it’s by design. Maybe we could expire it after N days of inactivity… ?
So it’s by design. The issue stays open because we could add an option to make the cookie expire after X days.
If a user has a tab open, then he won’t be logged out and that’s OKAY, that’s a different problem.