I am new to meteor.js and I am sorry if my question is not appropriate according to the community standards.
Well, I am trying to create a simple application on it and came across a problem of timing out after the user inactivity.
I am using "stale session meteor package" to automatically timeout the user after some specified time of inactivity. It logs off the user but doesn't unset the "Meteor.user()" by which I could know in meteor that the user has been logged out and call the route for the "Login" page to re-login.
Example, the stale session logs off the user after 30 seconds of inactivity, then I checked the returned value of "Meteor.user()", It should have returned undefined if the stale-session is timed out, instead, it is running the complete user object with id and other details.
I simply want to forcefully logout the user when the stale session times out and show the login screen.
I have been searching on internet for two days but couldn't find any solution on how to do this. Finally, posted the question.
I have found the solution and it is working so posting it here if somebody need.
I dug into the stale package code, and in its client.js I replaced the code with this
Meteor.setInterval(function() {
if (Meteor.userId()) {
if(activityDetected){
Meteor.call('heartbeat');
activityDetected = false;
} else {
//This is the wanted behavior
Meteor.logout();
}
}
}, heartbeatInterval);
If no activity is detected in terms of jquery events, I simply call logout and dont need to worry about Meteor.user() or Meteor.userId() etc. It simply logs out and goes to the Login Screen route which I implemented.
Related
In eXist 4.7 I implemented the persistentlogin in my controller.xql and I have noticed that it does not "persist" very long in my eXist web app ("thema"), whereas the eXide web app in the same eXist instance, using the same login function, persists authenticated status as expected.
Specifically, if I am logged in to both in the evening, the next morning eXide is still logged in (ie. authenticated = true), and my app is not.
I implemented it as follows, with duration set at 30 days ("P30D"):
import module namespace login="http://exist-db.org/xquery/login" at "resource:org/exist/xquery/modules/persistentlogin/login.xql";
let $duration := request:set-attribute("duration", "P30D")
let $set-user := login:set-user("org.exist.thema", (), false())
So I've further tested the persistence in my web app and I find that the login "disappears" (loses authentication?) after about an hour of being non-active on the site.
Is there some other eXist setting I've missed in configuring this?
The only documentation I've been able to find on this is in the notes in the code of login.xql: https://github.com/eXist-db/exist/blob/develop/extensions/modules/persistentlogin/src/main/resources/org/exist/xquery/modules/persistentlogin/login.xql
According to the source code for the login module, there are two ways to designate the duration for the login session:
Via the $maxAge parameter of the login:set-user function
Via a duration request parameter (which overrides the $maxAge parameter when present)
In your code, you are setting a duration request attribute, not a request parameter; for more on the difference, see this answer. This explains why the login module is completely ignoring your attempts to declare a duration.
To fix your problem, you could either (1) change to the first method:
login:set-user("org.exist.thema", xs:dayTimeDuration("P30D"), false())
... or (2) submit the request parameter in your login form, as eXide does in its login form; see https://github.com/eXist-db/eXide/blob/master/index.html.tmpl#L505-L528.
I am setting Mixpanel up, and I found out that if I log in with a user (and identify that user), log out and then re-register as a new user, the new user's details overwrite the previously logged in user (presumably when I call alias). How can I tell mixpanel that a user has logged out and to reset the identity token (make it anonymous again)?
I ran into the same issue, and after some sleuthing I discovered that you can manually clear the mixpanel cookies with mixpanel.cookie.clear().
However, you need to make sure that the mixpanel library has loaded, so I ended up putting it in a stupid timeout:
var id = window.setInterval(function() {
if (mixpanel.cookie && mixpanel.cookie.clear) {
mixpanel.cookie.clear();
window.clearInterval(id);
}
}, 50);
And then, since I didn't want to do this on every page, I added a query string parameter onto my logout redirect URL. So after visiting /logout it would redirect them to /home?_ref=logout, at which point I would clear the mixpanel cookie only if that query string parameter existed.
It was pretty annoying, but it seemed to work.
It was released on Mixpanel Javascript version v2.8.0 the mixpanel.reset() function, so that's officially what should be called on user logout. See https://github.com/mixpanel/mixpanel-js/issues/67 .
for android
on logout you can use this MixpanelAPI.reset()
Call clearSuperProperties() to remove any Super Properties in local
storage.
Set new_distinct_id = UUID.randomUUID().toString());
Call .identify(new_distinct_id) and .getPeople().identify(new_distinct_id)
This should wipe the device clean for a fresh user that can then register and be aliased to another distinct_id.
The best way to do this with javascript is to delete the cookie. The name of the cookie is mp_{mixpanel_token_id}_mixpanel
All,
in my liferay portlet when the session expires, the page gets redirected to login page.
Before redirecting to login page we are showing the message saying Session expired, redirecting to login page. Problem is that the message just flashes before the login page appears. I want to show this message say for some 3 sec before redirecting to login page. Is there any portal-ext property to specify this. My current contents of portal-ext.properties file is
session.timeout.warning=1
session.timeout.auto.extend=false
session.timeout.redirect.on.expire=true
help..
session.timeout.warning indicates the duration of the countdown warning.
For eg., if it is set to 1, it means User will be warned for 1 minute.
Below configuration in web.xml indicates that if User remains idle for 30 minutes without doing any activity, his Session will be destroyed.
<session-config>
<session-timeout>30</session-timeout>
</session-config>
For more details on this behaviour, please read this bug in session warning interpretation post.
As a side note there is a nice Jquery plugin for your requirement.
If you want Session to be destroyed after 30 mins but at 29th minute you want to Warn the User, then your code will look like below,
$j.idleTimeout('#dialog', 'div.ui-dialog-buttonpane button:first', {
idleAfter: 10440, // 29mins
..
..
Now as you know your session will expire after 30 mins. So, after 30th min, your session will expire and return to your configured page.
This is possible and you can take help of following JQuery plugin which provides this feature with customization at different levels. You can configure these customization when the plugin is initialized, like one below.
....
force: 300000,
....
https://www.jqueryscript.net/other/Session-Timeout-Alert-Plugin-With-jQuery-userTimeout.html
Demo: https://www.jqueryscript.net/demo/Session-Timeout-Alert-Plugin-With-jQuery-userTimeout/
I have multidomain web application which treats users differently based on URL they use.
I am using Session["data"] to keep information about user and starting this session with Session_Start["data"] in Global.asax.
All works fine but I would like to know what happens after inactivity. After certain time session will timeout. If that happens is Global.asax treating this as new user and will again start Session_Start for this user?
And will Session["data"] get updated with every page load/reload? Or because it starts just once and will timeout in some exact time?
I tried to make this question as clear as possible.
Thanks.
Session will renew/keep-alive everytime the server gets hit by that user.You set the timeout in the web config file and it is a sliding value, so it restarts again everytime there is a server request.
something like this:
<configuration>
<sessionstate
mode="inproc"
cookieless="false"
timeout="20" />
</configuration>
When the session times out, the next time there is a request, the Session_Start will execute. If you are accessing Session[data] from anywhere else in the code, you should check to make sure it is not null as it will throw a NullReferenceException if the session has timed out and you are trying to access it.
A new session starts when a user first visits a .NET URL (like an .aspx page, but not a .html or other static file) on your site. That session lasts until it times out or the application is killed (restarted/crashes/recycled). The default .NET timeout is 20 minutes; so a session will last as long as the user keeps hitting .aspx pages with no breaks longer than 20 minutes.
During that time, you can store information in the Session object that relates to that user. It is essentially a hashtable that you can populate with objects for which you define keys. In your case, you are using Session["data"], but you could use any key you want, really.
However a session, and the data you store in the Session hashtable, is very fragile (see all the ways it can die above). You shouldn't rely on it to keep anything important that can't be reconstructed easily (in Session_Start, for example). So it really serves two roles: maintaining state (so you know it is still the same user from page to page); and as a user-specific cache where you can keep data in memory to do things more quickly.
Session_Start just runs once per session--by definition. If you need to identify a single user over multiple sessions, you will need to use something more permanent like setting your own cookie with a far-future expiration. You can put an ID in such a cookie that lets you know this is user 12345 (in fact, Session_Start is just the place to look for your "permanent" cookie and connect your data about that existing user with this new session).
And if you want to store data about a user that survives multiple sessions, you will have to store that somewhere more permanent--a database being the most obvious solution. When they come back, you can cache some of that data in the Session hashtable--and Session_Start is just the place to do that as well. Hope this helps.
protected void Session_Start(object sender, EventArgs e)
{
// Code that runs when a new session is started
string RootURL = Request.ApplicationPath;
if (!RootURL.EndsWith("/"))
RootURL += "/";
Globals._rootURL = RootURL;
}
My host requires me to use a different domain for SSL secured access (shared SSL), so I need to transition the user session between two domains. One part of the page lives at http://example.com, while the SSL'd part is at https://example.hosting.com. As such I can't set a domain-spanning cookie.
What I'm trying to do is to transition the session id over and re-set the cookie like this:
http://example.com/normal/page, user clicks link to secure area and goes to:
http://example.com/secure/page, which causes a redirect to:
https://example.hosting.com/secure/page?sess=ikub..., which resurrects the session and sets a new cookie valid for the domain, then redirects to:
https://example.hosting.com/secure/page
This works up to the point where the session should be resurrected. I'm doing:
function beforeFilter() {
...
$this->Session->id($_GET['sess']);
$this->Session->activate();
...
}
As far as I can tell this should start the session with the given ID. It actually generates a new session ID though and this session is empty, the data is not restored.
This is on CakePHP 1.2.4. Do I need to do something else, or is there a better way to do what I'm trying to do?
When Configure::write('Security.level') is set to medium or higher, session.referer_check is implicitly activated, which makes the whole thing fail. Setting the security level to low (or using a custom session configuration) makes everything work as it should.
There went about 5 hours of debugging... ( -_-;;)
My first thought is to use the Cake file sessions and copy the file over, and then perhaps try and start a new session with that phpsessid, although I'm not even sure if that would actually work or not :)
With Cake 2.6.1 -- This is what worked for me.
$this->Session->id("tfvjv43hjmsnjkh0v3ss539uq7"); // add session id you want to set
$this->Session->id();
$this->Session->read("key"); // hhoorray worked :)
with SessionComponent id() function needs to be called twice once with session id to set session_id(); and second time to start cake session.
First call does not really start the session ... I dont know how Cake Guys missed it .....
Upvote if this works for you.