Tags:
advocacy1Add my vote for this tag twiki_community1Add my vote for this tag create new tag
view all tags

TWiki.org upgrade to TWiki 4.0

TWiki.org is in the process of being upgraded to TWiki 4.0.

Tasks & Status

Nr Task Who Status
1 Make outgoing e-mail work SvenDowideit Done after some delay
2 Discuss & decide on security implications of cookie based session tracking KennethLavrsen Proposal below
3 Upgrade all TWiki web topics to Dakar PeterThoeny, KennethLavrsen, ArthurClemens 50% done, how-to at ZzzZ
4 Install Perl libs SvenDowideit Done
5 Test-install Dakar in parallel to Cairo PeterThoeny Temporarily done with basic auth
6 Test test-installation with life data PeterThoeny Done
7 Copy user e-mails to .htpasswd with upgrade_emails.pl PeterThoeny Done with custom script
8 Convert 20K user home pages if necessary   Pending
9 Switch over to TWiki 4.0 PeterThoeny Done 2006-05-27
10 Plugin Files for download are not displayed FerdinandGassauer  

Decision on session tracking

With cookies and IP tracking (for security)

Upgrade all TWiki web topics to Dakar

All current TWiki web topics need to be upgraded to the TWiki 4.0 content, enclosed properly in header/footer & START/ENDSECTION as documented in DistributionDocument.

Convert 20K user home pages if necessary

TBD if to convert existing home pages. The new registration uses forms to keep the data, splits firstname and lastname, and there are additional changes. This makes it impossible to run meaningful reports with user home pages in the old and new format. If we upgrade, the question is what do do with the many missing/obfuscated e-mails etc.

-- Contributors: PeterThoeny

Discussion

We need to discuss & decide on security implications of cookie based session tracking. For example, as a site admin I work a few hours a day on TWiki.org. An intruder would not need to wait long to see my activity and steal a cookie session (in case possible.)

-- PeterThoeny - 20 Mar 2006

Can anyone sketch the security implications? Of course we need to make sure session ids can not figure in URLs (otherwise general access to url logs like i.e. awstats need to be closed, asap :-)), and that noone can read /tmp.

But except from that? I'd say CGI::Session is very secure in itself.

Didn't see any mention on which login mechanism we're aiming for, but if its the template login that is going to be used, known security measures apply (for protection against cross site scripting).

I am not familiar with current setup, but unless there's some kind of IP spoofing protection currently in place, current security could be a lot worse than session tracking will be.

-- SteffenPoulsen - 21 Mar 2006

It is essential to performance and daily use for users that we have the right combination of security and usability. IMHO using Sessions is OK as long as it is combined with IP matching. It is for sure more safe than the simple IP maching we have today on twiki.org. Sessions and quite normal in most websites today and it would take an attacker a great deal of effort to both get a session ID (not really easy) and spoof your IP. If you just authenticate for each page your password is sent in clear unless you buy a certificate and run https. And getting your password is worse because that does not have to be matched with IP address.

The settings I am recommending for a public Internet site (and I am using on my Internet Motion TWiki) are as follows - with focus on security.

Security

  • {UseClientSessions} ON
  • {Sessions}{Dir} /tmp
  • {Sessions}{ExpireAfter} -21600. Use negative value!! Means a lot to performance on a busy site like twiki.org. This must be combined with a crontab entry like 00 0,6,12,18 * * * root cd /usr/local/apache2/twiki/tools && perl -I /usr/local/apache2/twiki/bin tick_twiki.pl which cleans our session files every 6 hours and does additional cleanout of stale lease files from when a user edit and back out. Interval could be decreased to 3 hours.
  • {Sessions}{IDsInURLs} OFF - Users today all accept cookies. Turning this off prevents people from sending URLS including a valid session cookie ID in the URL.
  • {Sessions}{UseIPMatching} ON - This prevents an attacker from easily using a session cookie.
  • {Sessions}{MapIP2SID} OFF - Important to turn this off.

Authentication

I prefer Apache login because it allows IE to better remember password. But Template login looks much much better and think this should be chosen for the image of TWiki

  • {LoginManager} TWiki::Client::ApacheLogin
  • {DefaultUserLogin} guest - Default
  • {DefaultUserWikiName} - Default
  • {AdminUserWikiName} TWikiAdminGroup - Default
  • {SuperAdminGroup} TWikiAdminGroup - Default
  • {UsersTopicName} TWikiUsers - Default
  • {MapUserToWikiName} OFF - We use WikiName to login
  • {AuthScripts} attach,edit,manage,rename,save,upload,viewauth,rdiffauth - Default. Any additional plugins?
  • {AuthRealm} Use value which we use today

Passwords

  • {PasswordManager} TWiki::Users::HtPasswdUser
  • {Htpasswd}{FileName} Absolote path to data directory
  • {Htpasswd}{Encoding} Crypt - probably also what is used today. We will want to reuse password file
  • {Register}{AllowLoginName} OFF - We use WikiName to login
  • {Register}{HidePasswd} ON - Default
  • {Register}{NeedVerification} ON - Obvious choice to limit spam. This means new users must use valid password and an additional reason to set HidePasswd ON.

Paths

  • {SafeEnvPath} /bin:/usr/bin - Default

Miscellaneous

  • {DenyDotDotInclude} ON - Default
  • {INCLUDE}{AllowURLs} OFF - Could break a few things but I doubt it is important things.
  • {AllowInlineScript} ON - Default
  • {UploadFilter} (?-xism:^(\.htaccess|.*\.(?i)(?:php[0-9s]?|phtm[l]?|pl|py|cgi))$) - Default
  • {NameFilter} (?-xism:[\s\*?~^\$@%`"'&;|<>\x00-\x1f]) - Default
  • {ForceUnsafeRegexes} OFF - Default
  • {GetScriptUrlFromCgi} OFF - Default
  • {RemovePortNumber} OFF - Default
  • {AntiSpam}{EmailPadding} PLEASENOSPAM - Should be changed now and then to avoid that the email harvesters are programmed to expect the same static value.
  • {AntiSpam}{RobotsAreWelcome} ON - We want Google to index the TWiki so we can use this for searching. We are many that use this often.

Log Files I assume we log everything which is default

Localisation It will look good to show the new multilingual features. BUT this slows down TWiki by adding easily 30-50% extra execution time. And this gives a bad impression. I recommend turning it off for performance.

{DisplayTimeValues} gmtime - We are an international site and should use GMT

Mail and Proxy Default values except.

  • {SMTP}{MAILHOST} should either be an SMTP server that allows us to connect OR we use our own sendmail and then the value should be 'localhost'
  • {SMTP}{SENDERHOST} twiki.org

Plugins Default plugins all enabled.

  • However Wysiwyg can still cause trouble but it is an important showcase and new feature. We should probably enable it.
  • BlackListPlugin is a must
  • Plugins}{ChartPlugin}{Enabled} has always been there
  • {Plugins}{TWikiDrawPlugin}{Enabled} has always been there
  • Whatever extra.

When we install TWiki we should run the script tools/upgrade_emails.pl so that all email addresses get added to the htpasswd file. This enables users to remove or heavily distort their email address on their home page. We need to consider if we keep them visible or hide them if we make a convertion script for user pages. I would hide the email addresses. Our email address padding is not adequate any longer. We can send an annoucement about the upgrade of twiki.org and add in this that users can choose to remove their email addresses from display simply by editing their home page.

I hope all this will be a help in setting up twiki.org for 4.0.2

-- KennethLavrsen - 05 Apr 2006

Upgrade all TWiki web topics to Dakar ??? Dakar does that seamlessly as long as the old topic with tabs is format 1.0 in the header. So do NOT use the same data directory for Cairo and Dakar in an overlapping period. That will not work well

-- KennethLavrsen - 05 Apr 2006

Ugrade of TWiki web topics to Dakar is needed to address DakarDocumentationModelIsBroken. I am already making good progress on it.

-- PeterThoeny - 17 Apr 2006

Updated security proposal to Apache auth as agreed on Edinburgh meeting.

-- KennethLavrsen - 17 Apr 2006

TWiki.org runs TWiki 4.0.2 since 2006-05-27. Please report any problems you might encounter here.

The system web is temporarily set to the TWiki04 web. Once all important system topics of the TWiki web have been updated to TWiki 4 I will switch %TWIKIWEB% back to the TWiki web.

-- PeterThoeny - 27 May 2006

This may be because of the previous bullet, but I'm running into lots of pages with broken links over in the Plugins area, for example:

-- DougClaar - 31 May 2006

Thanks Doug, those links are fixed. They should point to TWiki webanyway, not to %TWIKIWEB%.

-- PeterThoeny - 01 Jun 2006

There is a report in UpdateInfoPluginDev that .tgz files are delivered with the wrong mime type. I fixed the data/mime.types file, and fixed the core, Bugs:Item2427

-- PeterThoeny - 06 Jun 2006

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2006-06-13 - FerdinandGassauer
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.