distributedINFORMATION.com

I’ve just updated the Experimental TWiki and Plugins repository. It now contains TWiki 4.2.0 and 212 Plugins, Contribs and Skins that you can simply apt-get install

To use them, add the following 2 lines to your /etc/apt/sources.list

deb http://distributedinformation.com/experimental/ experimental main contrib
deb-src http://distributedinformation.com/experimental/ experimental main contrib


then type

apt-get update

to update the available packages.

you can now see all 212 packages with apt-cache search twiki-

and install (assuming you don’t have twiki installed yet)

apt-get install apache2 twiki

and TWiki Contrib installation is as easy as

apt-get install twiki-bugscontrib

You will still need to use configure to enable Plugins.

Please report your experiences to me - bugs, gripes, you name it - its a work in progress. and I need your help!

I was having a discussion with someone on IRC about how TWiki is vulnerable to Cross-site scripting and Cross-site request forgery, and we realized that there are 2 possible approaches to securing TWiki effectively (both requiring a unique magic number for all URLs):

1. add a pre process to the TWiki::UI system, requiring a valid and unique magic, and a post process step between rendering and output to the browser
2. use a small proxy system between TWiki and browsers to add and validate the magic

1. is actually still risky as all scripts still are able to output directly to the browser using a =print= statement, thus giving the user urls that may not have a necessary magic in the url, or similarly for AddOns that persist in not using resthandlers.

whereas 2. abstracts the security from the application server, in much the same way as it is for ssl - goodness all round.

So - I wonder if there is such a proxy already?

There are also massive performance reasons why you should always have a proxy between browsers and heavy application servers like TWiki - this too could do with filling out.Securing TWiki is not as simple as converting all actions to POST (ie using proper REST / HTTP) because there are too many legacy conveniences, allowing GET URL’s to act upon the data. But, by delegating the securing of the transactions to an external wrapper, I think we can avoid these flaws.
see Wikipedia on Cross Site Scripting and Cross-site request forgery

I have just uploaded the OpenIDUserContrib for TWiki 4.2.0. It adds OpenID login and 1.1 Attribute functionalty to TWiki.

Currently, it disables Registration, and limits authentication to OpenID users.

It has the advantage over the OpenIDAuth apache module, that it automatically requests the User’s OpenId 1.1 attributes like Name, Email address directly from their OpenID identity.

While it trusts the user’s choice of ‘FullName’ registration attribute when displaying who made changes to topics, the TWiki topic source
actually stores the authenticating OpenID URI, thus their user details will be updated from the authentication server next time they log in.

Note that TWiki Topic based Groups are not yet implemented using this Mapper.

Future directions

• add mixing of UserMappers to allow OpenID and ‘normal’ TWiki auth
• turn TWiki into an OpenID identity server
• add Safe Group definition system
• add OpenId to TWiki’s registration process (would require openid auth first, then prefill registration details from any available attributes
  • This will require re-writing of TWiki’s inbuilt registration system
• move the list of Known users and their mapping information from data/OpenIdUsers.txt to somewhere more scalable. (perhaps DBI)
  • combine the info TWiki uses persistently with the Session and other caching info OpenID11? uses

Net::OpenID11 (based on Net::JanRain::OpenID)

To make this work, I fixed the Perl bugs I found in Net::JanRain::OpenID, and renamed the resulting modules under Net::openID11 (as it is not OpenID2.0). I expect to upload these packages to CPAN some time soon.

If you want to take a look at the code - goto my Subversion repository

These Windows, OSX, Centos and Fedora Core installers are fully integrated native installers that will update your Computer with perl, apache, rcs and other tools needed to run TWiki on that platform.TWiki 4.2.0 contains many new improvements to TWiki, including a much improved Wysiwyg editor, a structured query engine, a more generic authentication system and at the same time, the Core engine is faster than the previous twiki4 releases.The TWiki installers include native installs of (only installed if not already)

1. Apache 2.2 (Windows & rpm)
2. Perl (ActiveState - Windows & native for rpm)
3. Gnu Grep (Windows only)
4. Gnu rcs (All platforms)
5. TWiki 4.2.0 Release.

Please download it, try it out and report your impressions, ideas, bugs and successes here, on TWiki.org, or in the TWiki Bugs system.

• Windows TWiki installer 4.2.0  (23MB)
• Mac OSX TWiki installer (Tiger only I don’t yet own Leopard - donations welcome) 4.2.0  (2MB)
• Centos 4&5 and Fedora Core 5&7 4.2.0  (17MB)

Another TWiki innovation brought to you by distributedINFORMATION & WikiRing.com

For the extremely adventurous - I have built an installer using Strawberry Perl 5.10 beta2 - TWiki-4.2.0-rc2.1-strawberry.exe

Warning: Search does not work, and needs someone to debug it (I’m away over xmas)

I’ve been promising myself some time to try out DTrace on TWiki’s codebase for over a year. By following Bryan Allen’s
instructions using Richard Dawe’s adaption of Alan Burlison’s work… I now have a Perl 5.8.8 with DTrace probes.

Sounds great, except for one thing…. I now have to learn enough about DTrace to use it The patch that Alan and Richard have (or at least their DTrace scripts) seem to require a priori knowledge of the Perl process’ pid… not something thats going to work out for what I want to do.

For a quick test, DTrace -c ./view -s /export/home/sven/src/dtrace/subs-tree.d does show the program flow.

The following is while running some perl scripts - the 2 numbers are their pids.

# dtrace -l | grep -i perl

17803  perl17669        libperl.so                      Perl_pp_sort sub-entry

17804  perl17669        libperl.so                   Perl_pp_dbstate sub-entry

17805  perl17669        libperl.so                  Perl_pp_entersub sub-entry

17806  perl17669        libperl.so                      Perl_pp_last sub-return

17807  perl17669        libperl.so                    Perl_pp_return sub-return

17808  perl17669        libperl.so                     Perl_dounwind sub-return

17809  perl17669        libperl.so                Perl_pp_leavesublv sub-return

17810  perl17669        libperl.so                  Perl_pp_leavesub sub-return

88501  perl17760        libperl.so                      Perl_pp_sort sub-entry

88502  perl17760        libperl.so                   Perl_pp_dbstate sub-entry

88503  perl17760        libperl.so                  Perl_pp_entersub sub-entry

88504  perl17760        libperl.so                      Perl_pp_last sub-return

88505  perl17760        libperl.so                    Perl_pp_return sub-return

88506  perl17760        libperl.so                     Perl_dounwind sub-return

88507  perl17760        libperl.so                Perl_pp_leavesublv sub-return

88508  perl17760        libperl.so                  Perl_pp_leavesub sub-return

so… first ignorant modification - in subs-tree.d, it wants to trace perl$target:::sub-entry - change that to perl*:::sub-entry, and of course, it works exactly as I want - attaches to all subsequent perl process (running my dtrace-perl build) and tells me whats going on. The only caveat being that the DTrace script will only start if there is a Perl process running - the provider is obviously not persistent.

Brilliant!

Should be a fun Christmas holiday adventure - 410 pages of dtrace book, and a myriad of web pages to consume and digest.