Quick question - Is there any simple way (module perhaps?) to set the admin account to stay logged in forever?
I admin a bunch of Drupal sites and am getting really tired of constantly logging in after whatever interval it logs out automatically.
Use http://drupal.org/project/autologout
You can set the administrator to automatically logout after an insane amount of time (so it effectively becomes forever). Other users can be excluded from this setting so it does not apply to them.
Enable the module and checkout the settings at /admin/settings/autologout
This method is better than tweaking the session expiry related ini options in settings.php because then they apply to everyone and not only administrators. So it would have the bad side effect making everybody stay logged in forever.
P.S. these are the ini settings that determine session expiry in Drupal in settings.php
ini_set('session.cookie_lifetime', 2000000); // in seconds; approx 23 days
ini_set('session.gc_probability', 1);
ini_set('session.gc_divisor', 100);
// see http://www.php.net/manual/en/ini.list.php for explanations
No. The session is a function of your PHP installation (session controls) and your browser (it is a cookie-based session). For security concerns, I would highly recommend not doing that anyway.
Related
I need to provide the user with a way to start over. I'd like to clear the secured session cookie with a pipeline call but have found nothing in the docs.
I tried that once to reset a site session while the user logs out. The easiest way was to set the cookies in delete mode:
sid
pgid-[site]
SecureSessionID-[ID]
AuthenticationStateToken-[ID]
You can use the SetCookie-Pipelet for this. No custom-code is required.
Don't forget about all the other cookies your site sets: wishlist, cart, user, ... They might pull things into the new session you don't want to have.
Found the default pipeline - ViewUserAccount-LogoutUser.
That seemed to do the trick.
There might be a few questions here, but one major question... what should be implemented if we make a modal authentication work? Let me try to explain..
Current environment:
ASP.NET w/ .NET 4.0 w/ forms authentication
Our customers that use our lab software have to be extra cautious of another user taking control of their computer, so we can't implement persistent timeouts (I think the last time I read, you can keep extending the timeout as long as there's something happening in ASP.NET, right?). Even though we have password authentication throughout our laboratory rich client application, we still don't want a random person walking by some employees desk to see what they're working on and have something get compromised. So I've been thinking about this for quite some time and tonight I had an epiphany. What if we were to have the Login page pop up in a modal dialog within an iframe (or object tag) in a modal div that's inside of our masterpage? How can we keep their session from ever expiring, but require them to login after the session has timed out? Is there anything else you can think of that will be required if we were to implement something like this for it to work? Note, we have session variables within the software that cannot be reset if this occurs. How can we keep them persistent but still make this work? The main thing is I want to avoid having them be redirected to the Login page. This is rather annoying for end-users. By law, they need to have the timeout set to 2 minutes, so I thought this would be really cool if I can make it work. Any other things we need to watch out for??
I can't but think that it's scary to use asp.net session, especially with forms-auth - because, the user gets 2 cookies: session and auth. Imagine what would happen if, somehow, authenticated user A would steal session cookie from authenticated user B: it would result in user A having access to all data that user B owns (unless your code checks whether user-id from auth-cookie owns the session object. In other words, I would suggest to get rid of the session, or at least add user-id value to session object and make sure you check that user id from the auth-cookie matches that within application_authorize event, maybe. You didn't ask for this info, but I think it's appropriate, regardless.
Since the session and the auth cookies have little to do with each other, as far as browser is concerned, and your goal is to keep the session alive, while auth-cookie should expire, then, you can maybe solve that by writing a piece of JS (hint: window.setInterval) that regularly pings some ANONYMOUS url (aspx page) at your server (make sure you add a random query to those requests; e.g. new Date().getTime()). The anon aspx page would need to read (do not write!) some value from the session (or simply retrieve the session object) - just to keep it alive (maybe this isn't really necessary; do experiment), but the browser WILL be sending asp.net session cookie with these requests, so you can keep the session object alive forever this way.
On the other side, your auth-cookie will expire. However you MUST set web.config settings (authentication > forms) to NOT use sliding expiration (as that mode essentially extends the validity/expiration of the auth cookie for another whatever-the-timeout-is minutes). Then, you can be sure that, after the cookie expires (e.g. after 20 min), when the user clicks on a protected link (well, a link that links to protected page; non-anon page), then they will land on login page. I know that you don't want this. So, to solve that, add another (independent) piece of javascript (hint: window.setTimeout([code], 2 * 60 * 1000) // to fire after 2 min since the page-load) to launch the login dialog. The login dialog would extend the auth-cookie by posting the uid/pwd and letting asp.net validate it.
Another thing: if you have ajax going on on that page, you must think of resetting these js timeouts back to 0 (or cancelling then reinitializing interval and timeout events). In other words, you can't start measuring inactivity since the page load - you have to reset the inactivity counter on every user's action (click; or at least on every ajax callback).
What I'm suggesting here may be an overkill. I would probably try to solve this differently. I would try to eliminate in-process session from the picture, and reload it based on auth-cookie's user-id from whereever user data is, every time it's needed (or once per request). I don't know why it's so important to keep the session object hanging in memory, even when the user is logged out (how do you know they won't leave for a week; keeping sessions alive would be killing your server if you had a large number of users). Maybe store the session data in database or some other caching mechanism on the network (e.g. memcached) and retrieve it once per request (e.g. in application_authorize), store it in request.context (to eliminate retrieving it multiple times from multiple places). Then, your auth-cookie will expire, and use JS to popup the login dialog a few min before the auth cookie expired (to avoid the gap where the user will land on login page if they click on a link, if you care about that even).
I hope these ideas help.
In Flash, I have the ability to save certain info onto the server.
Now the problem is the user needs to be authenticated as admin in order to do so.
I can't use sessions, since if you work longer than 20 minutes in the Flash application,
the session is gone.
The way I see it, I have 2 possibilities:
1. passing a parameter (bIsAdmin) to Flash from the Website.
2. Launch a http-get request, to get this value (bIsAdmin) from an ashx handler
on application startup, when the session has not yet exired.
In my opinion, both possibilities are not really secure...
So, which one is safer, 1 or 2?
Or does anybody have a better idea ?
In my opinion, 1 is safer, because with 2, you can just switch a packet tamperer in between,
and bang, you're admin, with permission to save (or overwrite, =delete) anything.
Both are insecure. Analyzing the Flash code any user can discover the presence of the blsAdmin parameter and try generate the request to gain admin privileges.
Remember that the Flash applications can be decompiled and analyzed by anyone using tools as Flasm or SWFDump.
My solution? Use sessions to store the admin privileges. If the session is going to expire in 20 minutes generate a request every 10 minutes to a dummy page in the server to keep the session alive but this is also a bad practice. If you are an admin user you don't have to leave your application unattended in any moment without logging out when you finish using it.
Ta Ta,
I'm trying to implement a 'remember me' functionality on my website to allow the users to remain logged in without having to login again.
I do something like this:
System.Web.Security.FormsAuthentication.SetAuthCookie(userName, true);
I've noticed that the 2nd parameter (createPersistentcookie) is not really persistent as it depends on the timeout value set in the config file.
From what I understand:
if createPersistentcookie=false then the user will automatically be logged out if s/he closes the browser or after x minutes of activity (x being specified in the config file).
if createPersistentcookie=true then the user will NOT be logged out if s/he closes the browser but will still be logged out after x minutes of activity (x being specified in the config file).
Note that in both cases 'x' has the same value and comes from the config file.
What I would like to do is:
-if the visitor doesn't want to stay logged in all the time I would like him to be automatically logged out after 20mn of inactivity of if he closes the browser. To do this I would set createPersistentcookie to false and the timeout value to 20mn.
-if the visitor DOES want to stay logged in all the time I would like him to be automatically logged out only after 7 days of inactivity. Closing the browser won't log him out. To do this I would set createPersistentcookie to true and the timeout value to 7 days.
You see the problem: in one case the timeout is set to 20mn and in the other case the timeout is set to 7 days but in the config file I can only specify 1 value.
Any suggestions?
The title and first part of the question is in conflict with what you ultimately state as your goal.
To address the first part:
You need to construct the ticket yourself and explicitly set the expiration on the COOKIE the same as the timeout and then set the cookie.
This is easier said than done, because MS in it's infinite wisdom does not expose the timeout property of the formsauthentication element. There is a pretty simple workaround.
See the code in this answer to see what is required to create persistent tickets.
In conclusion: You are not doing anything wrong, the createPersistentCookie functionality is broken but can be worked around.
To address your stated goal:
There is really no clean way to do this using FormsAuthentication. Any attempt to do so would result in brittle hacks around a well designed, secure system that is dead simple to implement and leverage. If you attempt this with forms auth you will find yourself chasing ghosts.
good luck.
You can set expiration time programmicaly. Authentication cookie can be decrypted to FormsAuthenticationTicket using FormsAuthentication.Decrypt(). Then you can re-create the ticket by setting expiration time.
createPersistentcookie means whether cookie will be destroyed when user closes browser or not. You can specify very long lifetime and persistent cookie for remembering the user
Why do i have to use some persistent-login module to make my users login into Drupal 6
for longer period of time.
Why changing php.ini or settings.php doesnt works ?
from a "webtools" I see my cookies being expired in next day, but after few hours it happend to log me out.
This is like spontagenious action, no pattern to follow / predict.
why this "keep-alive" login exists in drupal ??
You do not have to use the persistent module to achieve longer log in periods. You can simply adjust the ini_set() calls for the session.* PHP settings in your Drupal instances settings.php file (especially session.cookie_lifetime and session.gc_maxlifetime).
If adjusting those does not work for you, you should ensure that your server configuration allows overriding them from PHP.
Also, Drupal uses the standard PHP session storage mechanisms - if there are other PHP apps running on the same server, they might interfere with your session lifetime settings, depending on storage path configurations. See point 2 in this answer for information on that.
The persistent login module aims to make the configuration easier, but especially adds more features, as e.g. allowing a general remember me option while still requiring reauthentication for sensitive operations (like changing the password) to minimize the risks associated with long login periods.
Check this article linked from the modules project page, as well as this article linked from there for some in depth explanations concerning the handling of persistent logins.
Drupal overrides the internal php session save handler in include/bootstrap.ini and has some non standard session code there. Haven't followed it through though.
Beyond that Drupal's settings.php will override php.ini.