I'm using grails 1.3.5 and I need to automatically log out users from my app when they close their browser or all tabs in which my app is opened.
While there is no particularly reliable way to do this (in any web framework, not just Grails), there are some rather hacky ways you can get close to this, though there are some massive tradeoffs.
In general, since you have a default session timeout, the user will be logged out (in general) when their session expires due to not receiving a request associated with their session. This behavior can be changed depending on your security environment, but we'll assume you are using (sensible) defaults.
This session expiration logout can be abused to mimic logging them out when they have no windows/tabs with your application open in them. To do this, you could have a small piece of JavaScript that continually "pings" your server at whatever interval you specify to keep the session "alive" and keep them logged in. How tight you set these pings is a tradeoff between the load on your server and the window of time where they could close their browser and re-open it and still stay logged in.
Like I said, this is very hacky, but it's functional.
Related
I have a process that runs as root in the background. When a certain even occurs, I have it pop up an NSAlert with an NSTextField on it so the user can provide some info. However, the user is unable to click on the TextField or type anything into it. I can drag the Alert box around and click on the buttons on the Alert just fine.
I'm guessing this is because my process is running as root and not the end user account that is logged into the machine. Is there a way to easily get around this without spawning a separate process as the user and piping back the info via Distributed Objects or the like?
The best thing to do is to have your UI stuff running as the current user, not only because of problems like this, but also because running a GUI app as root poses a large number of security risks, and in fact there have been a number of security vulnerabilities in the past which were caused by some AppKit-enabled process running as root.
With that said, XPC is the mechanism you want to use to communicate between the root tool and the GUI app, not Distributed Objects, which is quite antiquated and has a number of issues of its own.
When we deactivate a WP app, it can be tombstoned and terminated later by the OS. I need to save some unsaved app data to a persistent storage when the process is terminated, but not before this. Obviously, the Deactivated event cannot be used for this purpose as it is raised immediately when an app is moved to the background; the Close event is also not the event we need as it si not raised when the app process is terminated by the OS. Is there a special Windows Phone app event for that, something like Application_Terminated?
The problem is that the operating system only tombstones your app when it is under severe resource pressure. At the time it is not practical to wake up the app and run app code because it might risk whatever is currently in the foreground. This limitation exists on all modern mobile operating systems (Android, IOS included). This is just the cost of operating in a battery/resource friendly environment.
Having said that, it sounds like your backing store does not disambiguate between data the user "saved" and data that is just being cached until the user can finish the transaction. It would be useful to build the idea in. Think of it the way some of the smarter web sites on the internet now work. You can navigate away while you were in the middle of entering data and when you come back the site presents you with the partially filled form. The site understands that you weren't "done" but it respects the fact that you had provided some of the information you'd need to get "done".
What I'm saying here is that the problem is easily fixed by understanding and accommodating the way your users are likely to use the app. Thinking of your app like a web site (at least in this context) helps out things into perspective. Sorry about the longish answer. I hope it helps :)
There is no such event. You should save your state on Deactivated so that if the application is removed from memory (tombstoned) you can set yourself up again upon reactivation. If your problem is figuring out whether or not you need to restore state on Activated, check out the ActivatedEventArgs.IsApplicationInstancePreserved flag (http://msdn.microsoft.com/en-us/library/windowsphone/develop/microsoft.phone.shell.activatedeventargs.isapplicationinstancepreserved(v=vs.105).aspx). This flag tells you whether your app was tombstoned. If it wasn't, you can throw away the old state or overwrite it the next time you are deactivated.
I set up a test version of a PHP coded website which uses sessions to handle user logins. On the test server, the session would expire on browser close, since copying everything to the "clean" live server, the session stays in place on browser close and the user is still logged in even the next day after full system reboot.
In php.ini
; Lifetime in seconds of cookie or, if 0, until browser is restarted.
; http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime
session.cookie_lifetime = 0
Which implies that it should expire on browser restart.
I thought maybe it was being overridden somewhere, but if I print_r the session_get_cookie_params in PHP I get
Array
(
[lifetime] => 0
[path] => /
[domain] =>
[secure] =>
[httponly] =>
)
Is there something I am missing?
If you are using google chrome
if you set "continue where I left off", chrome will restore your browsing data and session cookies.
even Facebook login (without "remember me") session is retained.
for more info
google chrome setting
Issue is here that a Firefox has a feature called "Restore last session". If someone uses saving tabs on close then it's the same. When browser restores the last session then all session cookies will be restored too :)
So your session cookie can live forever. You can read more at Firefox session cookies
I was going to add this as a comment on Alexander's excellent answer, but its going to get a bit verbose.
How long the cookie is retained on the browser and how long the session data is retained by the server in the absence of a request are 2 seperate and independent things. There is no way to avoid this due to the stateless nature of HTTP - although there are some things you can do to mitigate what you perceive as a security flaw.
For the browser to access the same session after being closed down and some delay it requires that both the session cookie be retained by the browser (which Alexander has already explained) and for the server to have retained the session data.
The behaviour you describe may be much more pronounced on systems handling a low volume of requests and where the session handler does not verify the TTL of the sesion data (I'm not sure if the default handlers do, or if they just assume that any undeleted session data is considered current).
You've not provided any details of how the 2 servers are configured, notably the session.gc_maxlifetime.
If the session.gc_maxlifetime has expired between requests but the session data is still accessible this implies that the session handler merely considers this as the time at which the session is considered eligible for garbage collection (which, semantically, is what the configuration option is for). However there is a strong case for treating this value as a TTL. To address this you could either force the garbage collection to run more frequently and delete the session data, or use a session handler which ignores session data older than the specified limit.
That you see a difference between the 2 systems may be due to differing values for session.gc_maxlifetime or differences in the frequency of garbage collection or even different session handlers.
Good morning. I have an application that queries a REST source. It needs to run continuously, capturing data which is refreshed every five minutes, without fail. My solution is Task Scheduler, where the app is set to launch on server boot. Once launched, it uses a timer to re-query periodically. The TS task is set to repeat every five minutes, with the check box "if app is already running, do not start another instance," so if the app crashes it should restart automatically within five minutes.
This works fine, but TS launches the app invisibly. I'd feel warmer and fuzzier inside if I could see the app, just as if I'd launched it myself. Also, if I need to close it (e.g., to post a new exe), I have to kill it via Task Manager; ouch. I've gone over the TS options a dozen times for some kind of "launch in foreground" option, but none exists. Can anyone tell me what I'm missing?
Notes:
From my web searches, it's clear that an app is only allowed to interact with the desktop if it's running under the same user account... but it is, I'm using my AD account, not SYSTEM or another local account.
It's acceptable for the app to only be visible to me, though even better would be if other users could also see and interact with it. I suppose the only way that would work would be if each user had their own monitor app which just reflected results exposed from a single invisible app which actually did the work.
I get the same behavior if I start the TS task manually or if it launches on boot automatically.
"Run only when the user is logged on" won't do, as I need it to resume even if the server restarts in the middle of the night.
I had been launching the app with a little PS script, so I could send a notification if the app failed to launch at all, but there's no change if I have TS launch it directly.
I suppose the proper solution would be to write this as a service. I put some time into that, but I haven't done that before and couldn't get it running. If the consensus is that that would be a better approach, I'll give it another try.
Any ideas? Thanks!
If you set the task to "run only when user is logged in" then it will be visible for you if you uncheck the "hidden" box.
If you have the "Run whetever user is logged on or not" choice checked, then it will be hidden even if you uncheck the "hidden" box. The implementation of Task Scheduler doesn't allow you to run programs in the foreground if you aren't logged in.
To solve this you can create a user that does AutoAdminLogon and start the application with the Startup script. By doing it this way, you will make the server log in with this user on boot and start the program you want.
If you then want to check how it's going or so, you can login as that user or switch to that session.
Does grid computing continue when the user is not logged in - for instance, on an educational system, where students must log in, when the log out, does the cpu continue the cloud computing? Or in another instance, if I use my home computer for something like superdonate.com, does the processor still go if I log out?
It depends on the client and how it is set up. But I think most clients continue to work when you log off.
The whole purpose is to use the computer when it is idle after all.
Your question is very generic. Technically, if you have delegation of credential, yes. In Globus you delegate authentication credential to a third part, and it will continue acting on your behalf even if you "log out".