• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.
Some users have expressed a need to keep their sessions alive indefinitely, so they don't have to login out / log in on a single computer.


This isn't the first time this has been asked for.

The workaround is to find the cookie creation lines in Client.pm and hack the code:

    my $c = CGI::Cookie->new( -name => $CGI::Session::NAME,
                              -value => $this->{_cgisession}->id(),
                              -path => '/' );
and add an expiry time e.g.
for three months.

The default is for the cookie to expire when the browser is closed. It is probably appropriate to provide a configuration setting for this.


I suggest an input field in configure for the number of months. '1' for 1 month, '12' for 1 year.


Whatever value is chosen - this should not be marked as a "Release blocker". This is an enhancement, and can wait until all open bugs for 4.1 are sorted out.


Harald is right. This is a new feature and we will never get 4.1 released if we keep on implementing enhancements.

I agree with the feature though.


I have added the patch for the checkbox on the login screen to SVN, but made hidden. If the core code is ready it can be made visible.


My fault, I marked it as a requirement because it is a requirement, in the classical sense of the word. I had forgotten we treat those as release blockers (again my fault, sorry). It's also an enhancement, so it's perfectly fine to rescale it as such. We need to think about our definition of "release blocker", I think (though that's another discussion). I agree it should not be in 4.1.

Arthur, what did you check in? Is that part of Chad Parry's patch? http://twiki.org/cgi-bin/view/Codev/RememberCookieLogin


I've reverted my commit. My patch is in TWiki:Codev.RememberCookieLogin.


The following is from CGI.pm documentation. When choosing an expiration date format for cookies, it must follow the pattern in this table. Upper and lowercase is important. smile The example confused myself and a dev assisting me as we assumed +3Y would be 3 Years when in fact, its not even valid.

+30s 30 seconds from now
+10m ten minutes from now
+1h one hour from now
-1d yesterday (i.e. "ASAP!")
now immediately
+3M in three months
+10y in ten years time
Thu, 25-Apr-1999 00:40:33 GMT at the indicated time & date


I'll work on adding documentation and localization to the patch. Do people prefer to have a configuration option to set the length of time that cookies are remembered? There's already so many configuration options that I would prefer not to add another one. I recommend always enabling the feature (as long as sessions are enabled) and setting the duration to 6 months.


Lets do it without configuration, but I would like to give user feedback about the duration (as checkbox label).


I do not think people can use this information for anything. They do not care if it is 6 months or 12 months. Both are forever. I have never seen a "Remember Me" checkmark that annouced how long. This is the type of feature where the configuration should be turned on or turned off. And when turned on the duration should be looong. It does not matter if it is 6 months or 12 months or 100 years. They are all forever in any practical sense.

How will you add a checkmark to Apache login? When you use an LDAP authentication, Template login will not work.


I've updated the patch (in TWiki:Codev.RememberCookieLogin) based on these suggestions. The duration of the cookie can be set with a constant in Client.pm but it is not a configuration variable.

The duration is now measured in days, because it's easier to convert from days to seconds than from months to seconds. The expireDeadSessions subroutine needs to know how many seconds to preserve each session file.

If a site uses Apache login, then I recommend that this functionality should not be provided. As TWiki:Main.CrawfordCurrie said, "Most browsers have a password memory option that will remember passwords." I have a related question though. Is it important to hide the "remember me" check box on sites that have disabled cookies?


Getting there, Chad! But I'm afraid the patch can't be applied just yet, sorry. Reasons:

  1. The rationale for remembering sessions is to avoid users having to repeatedly log in on a single computer. Since most (ApacheLogin based) login managers cache login info in the browser, then this is only needed with TemplateLogin (and subclasses thereof). So the implementation should be entirely within Client/TemplateLogin.pm. Client.pm should not be touched if possible (though you may need to improve the abstraction in Client.pm to support overriding relevant code in subclasses. For example, note that there should be a _setCookie method in Client.pm that implements the cookie adding, as that code is currently duplicated. If there is a _setCookie method you can override it in the TemplateLogin subclass). I see no value (and some risk) in supporting immortal cookies with other login managers.
  2. You should use a context variable to determine whether the "remember" UI is appropriate or not. in TemplateLogin, $session->enterContext( 'can_remember_login') and then in login.pattern.tmpl ==. That avoids the UI appearing inappropriately with non-template login managers.
  3. expireDeadSessions already honours the {Sessions}{ExpireAfter} config var. I don't see any value in additionally timing out based on the login memory.
  4. The default and Classic skin templates need updating with the new UI switch.
  5. The documentation needs to be improved. There is no description (for the user) that I can find of what the "remember" switch actually does.

Sorry to hit you with all this, but it's important to consider all the angles when making core changes.


Thanks for explaining the abstraction layers. I didn't even realize that "TemplateLogin" was a subclass. What does "Template" mean in this context?

Here is another update to the patch. This incorporates your suggestions.


I think Chad did a terrific job by fulfilling all above requests. If someone (CC) can have a look at the code part, I can integrate the other changes.


Looking into it


'Template' means fuelled by a TWiki template. The name was a poor choice.

OK, I had to make some logical changes, but it's all in. Thanks, Chad! Though there is still no documentation of what "Remember me" does - Arthur, i assume you will provide that in the template.


Yes, I can add this info to the template.

One more thing: I want to show the checkbox only if ExpireCookiesAfter is set to more than one day. In any case it should be larger than 0. How can I retrieve this value?


I already coded that, using the context identifier can_remember_login


Cleaned "WaitingFor" field.

-- TWiki:Main.GilmarSantosJr - 10 Aug 2008

Summary Allow infinite expiry of cookies
ReportedBy TWiki:Main.CrawfordCurrie
Codebase 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5, ~twiki4
SVN Range TWiki-4.1, Tue, 28 Nov 2006, build 12081
AppliesTo Engine

Priority Enhancement
CurrentState Closed

Checkins 12166 12169 12837 12859
TargetRelease minor
ReleasedIn 4.2.0
Edit | Attach | Watch | Print version | History: r30 < r29 < r28 < r27 < r26 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r30 - 2008-08-10 - GilmarSantosJr
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback