Log inRegister
You are here: Boossy » WikiFoswiki » FwIssues

FOSWIKI issues

Wrong translations

  • login page:
    • source: Having problems logging in?
    • translation: Probleemen bij het inloggen?
    • corrected translation: Problemen bij het inloggen?

Rename / Delete topic

  • Rename/delete a topic resulted in an error, although the rename/delete action succeeded.
    • Error in ~/working/logs/error.log: Compilation failed in require at /home/boossybe/domains/boossy.be/public_html/wiki/lib/Foswiki/Plugins/SolrPlugin.pm line 216.
    • solution: disabled the SolrPlugin...
  • Rename a topic that is referred to in a %TREEVIEW%: the topic name is renamed in the %TREEVIEW%, but is not surrounded by double quotes and so doesn't work!

Copy / View revision history / View last change (24/07/'19)

After I switched to the !NatSkin skin, the commands Copy / View revision history / View last change resulted in a 500 error.

Copying the attach command as copy and diff command solved this issue.

See FwCommands.

Encode object version 2.51 does not match bootstrap parameter 3.01 (21/06/'20)

Ik surf naar wiki.boossy.be en ik krijg meteen een vieze Software error in mijn gezicht gegooid:

Encode object version 2.51 does not match bootstrap parameter 3.01 at /usr/lib64/perl5/DynaLoader.pm line 213.
 at /usr/lib64/perl5/DynaLoader.pm line 213.
   DynaLoader::bootstrap('Encode', 3.01) called at /usr/lib64/perl5/DynaLoader.pm line 105
   DynaLoader::bootstrap_inherit('Encode', 3.01) called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 12
   Encode::BEGIN() called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   eval {...} called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   require Encode.pm called at /home/web00929/domains/boossy.be/public_html/wiki/lib/Foswiki/Configure/Load.pm line 22
   Foswiki::Configure::Load::BEGIN() called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   eval {...} called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   require Foswiki/Configure/Load.pm called at /home/web00929/domains/boossy.be/public_html/wiki/lib/Foswiki.pm line 53
   Foswiki::BEGIN() called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   eval {...} called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   require Foswiki.pm called at view line 28
   main::BEGIN() called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   eval {...} called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13

Tijdelijke oplossing

/home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm hernoemd naar _Encode.pm

MAAR: nu werkt de mail niet meer in de wiki…

Oorzaak & oplossing

  • DirectAdmin: Extra Features > !cPGuard Security
      => restored from backup (~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/Encode.so)
      hierna ging het mailen nog niet, XS.so vereist
      => restored from backup (~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Email/Address/XS/XS.so)
      hierna ging het mailen wel opnieuw

Andere terug te plaatsen, verwijderde .so-bestanden

  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/Byte/Byte.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/CN/CN.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/EBCDIC/EBCDIC.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/JP/JP.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/KR/KR.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/Symbol/Symbol.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/TW/TW.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/Unicode/Unicode.so

406 Not Acceptable / 403 Forbidden (21/06/'20)

today (21/06/'20) I wasn't able to login to one of the public webs on my foswiki site.

When I click the log in link, I get:
You don't have permission to access this resource.

Also other public webs (e.g. Main) are visible, but can't be logged in to.

One workaround to log in, is to go to a private web, where immediately the login form is shown, then log in, then go to the public web…

Another workaround is to delete the query string from the url:

FORBIDDEN: http://wiki.boossy.be/bin/login?foswiki_origin=GET%2cview%2c/bin/view/Boossy/WebHome

WORKAROUND 1 OK (private web): http://wiki.boossy.be/bin/view/Yssoob/WebHome

WORKAROUND 2 OK (no query string): http://wiki.boossy.be/bin/login

The link starts to show the logon screen if I shorten it upto: http://wiki.boossy.be/bin/login?foswiki_origin=GET%2cview%2c/bin Once I add another slash, I get the error!

In the meantime (23/06/'20), the message has changed, but the workaround still work:
Not Acceptable
An appropriate representation of the requested resource could not be found on this server.

According to the hosting company, a weekly update had been executed on the shared servers.

DirectAdmin (Apache) Error Log

It took me some time before I realised that the usage and error log I was looking at, was from the domain only, not of the subdomains:
  • in DirectAdmin, go to System Info & Files > Site Summary / Statistics / Logs
  • click on the name of the subdomain that is throwing the error (wiki.boossy.be) and choose Error Log
ModSecurity: Access denied with code 406 (phase 2). 
Match of "contains /wp-admin/admin-ajax.php?action=ime_test_im_path" against "REQUEST_URI" required. 
[file "remote server"] 
[line "-1"] 
[id "410009"] 
[msg "Malware.Expert - query_string: unwanted shell access"] 
[hostname "wiki.boossy.be"] 
[uri "/bin/login"] 
[unique_id "XvMGeb5Rwa83WZiDXjWScwAAAXk"], 
referer: http://wiki.boossy.be/bin/view/Boossy/WebHome

It's clearly meant to avoid access to WordPress admin pages, so it's a false positive in my case (my URL is e.g. http://wiki.boossy.be/app/login?foswiki_origin=GET%2cview%2c/app/view/Boossy/WebHome), but not wanting the hosting company to bother them with an exception only for me, I figured out a solution.

I tried three possibilities:

(0) disable mod_security for wiki.boossy.be

<IfModule mod_security2.c>
   SecFilterEngine Off
   SecFilterScanPOST Off

  <IfModule mod_security2.c>
    SecRuleRemoveById 410009

But this didn't work, I suppose the hosting company didn't allow my configs.

(1) use short URLs

Inspiration First, I added this to the root .htaccess:

# RewriteEngine On (is already on, so that's why I comment it here
RewriteRule ^([A-Z].*) /home/web00929/domains/boossy.be/public_html/wiki/bin/view/$1 [L]
DirectoryIndex /bin/view

Then I adapted the Foswiki Configuration accordingly:
  • General settings, Web URLs and Paths:
  • Script Url Path: /bin
  • Script Url Path for View:
So I emptied the Script Url Path for View

This effectively solved the problem, but I had no skin (no css)...

Navigating to a .css file also threw an error, e.g. http://wiki.boossy.be/pub/System/PatternSkinTheme/style.css
%ORANGE% _403 Forbidden - You don't have permission to access this resource._ %ENDCOLOR%

In the error log, you read:
%ORANGE%<i>[rewrite:error] </i>%ENDCOLOR%
%ORANGE%<i>AH00670: Options FollowSymLinks and SymLinksIfOwnerMatch are both off, </i>%ENDCOLOR%
%ORANGE%<i>so the RewriteRule directive is also forbidden due to its similar ability to circumvent directory restrictions : </i>%ENDCOLOR%

Also, attachments weren't accessible and images weren't shown, indicating navigating to the pub directory content wasn't allowed.

Adding a .htaccess to the /~/pub folder with the following line solved the problem:
%ORANGE% _Options +SymLinksIfOwnerMatch_ %ENDCOLOR%

I hope this doesn't imply a security risk...

Strangely enough, one day later, the !+SymLinksIfOwnerMatch isn't necessary anymore...

Finally, in order to get the WebHome of my most used web, instead of using a Redirect in .htaccess (which didn't work anymore), I used the built-in !HomePagePlugin in the Foswiki Configuration:
  • navigate to ~/bin/configure
  • choose Extensions in the left bar
  • click on the !HomePagePlugin button/tab
  • fill in the needed value in {HomePagePlugin}{SiteDefaultTopic}: Boossy
Save the changes.

(2) symbolic link to bin

Before I tried the short URLs solution, I had another solution/workaround, i.e. a symlink to the app directory:
ln -s bin app

Then I had to change the redirect in the .htaccess of wiki.boossy.be as well:
# Redirect /index.html /bin/view/Boossy/WebHome
Redirect /index.html /app/view/Boossy/WebHome

And finally I adapted the Foswiki Configuration accordingly:
  • General settings, Web URLs and Paths:
  • Script Url Path: /app
  • Script Url Path for View: /app/view
Save your changes.

This finally solved my problem.

403 when trying to edit the topic Win10AppShortcut

  • in DirectAdmin, go to System Info & Files > Site Summary / Statistics / Logs
  • click on the name of the subdomain that is throwing the error (wiki.boossy.be) and choose Error Log
[Tue Oct 13 21:49:05.796292 2020]
[pid 350394:tid 140396248008448]
[client] [[ModSecurity][ModSecurity]]: Access denied with code 403 (phase 2). Pattern match "(?:\\\\n|\\\\r)+(?:get|post|head|options|connect|put|delete|trace|propfind|propatch|mkcol|copy|move|lock|unlock)\\\\s+" at MATCHED_VAR. [file "/usr/local/cwaf/rules/12_HTTP_Protocol.conf"]
[line "137"]
[id "217280"]
[rev "6"]
[msg "COMODO WAF: HTTP Request Smuggling Attack||wiki.boossy.be|F|2"]
[data "Matched Data: get found within MATCHED_VAR"]
[severity "CRITICAL"]
[tag "CWAF"]
[tag "Protocol"]
[hostname "wiki.boossy.be"]
[uri "/bin/rest/WysiwygPlugin/tml2html"]
[unique_id "X4YEsbm@82iv9hHt0-6aVgAAGjg"], referer: https://wiki.boossy.be/bin/edit/Boossy/Win10AppShortcut?t=1602618538

A hint to the answer, I found here. Apparently, in the web hosting control panel Plesk, you can adjust settings in the Web Application Firewall.

I found out this can also be achieved in !DirectAdmin, the control panel used by my web hosting company:
  • Account Manager > Domain Setup
  • click on your domain name
  • in the top right corner, click on !ModSecurity
  • now scroll down to Disabled Rules
  • in the ID text box, fill in the id you found in the Error log and click on the DISABLE RULE button: the ID is added to the list with ModSecurity Disabled Rules
Afterwards, I was able to edit the topic.

Expires header in /pub directory (26/06/'20)

In the default .htaccess delivered in the /pub directory, the mod_expires lines are commented out, but it is mentioned that it reduces the load on the server significantly and that you should enable it if you can, to get an improved foswiki experience, so I did…

<ifmodule mod_expires.c>
  <filesmatch "\.(jpg|gif|png|css|js)$">
    ExpiresActive on
    ExpiresDefault "access plus 11 days"

Relocate local Perl lib & CPAN lib (26/06/'20)

These libraries were located in /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi, so public.
  • I moved them to /home/web00929/perl5/x86_64-linux-thread-multi
  • and changed the variable accordingly in ~/bin/LocalLib.cfg:
@localPerlLibPath = ( '/home/web00929/perl5/x86_64-linux-thread-multi', '/home/web00929/perl5/x86_64-linux-thread-multi/CPAN/lib' );

Then I did a test to send a mail (which definitely makes use of such a lib), and this went fine!

Clean environment variables and $PATH variable

After that, I still wanted to clean the environment variables and get a clean$PATH variable.

Source: https://www.tecmint.com/set-unset-environment-variables-in-linux/

I always used set to see the variables, the site above mentions env.

The output is different, the difference between the two commands is explained here: https://www.linuxquestions.org/questions/linux-general-1/set-versus-env-265773/#:~:text=env%20is%20a%20program%20that,brace%20expansion%20within%20the%20shell.
set is a shell command to set the value of a shell attribute variable; these are internal variables used by the shell.

env is a program that runs another program with modified environment variables.

The major difference is that the env command will never modify the shell's own environment (only that of the child process), while set will. Set can also change settings like brace expansion within the shell.

You might also want to look at export, which changes the environment variables for all future commands.

All variables I wanted to modify, were user environment variables, defined in ~/.bashrc. (~ = user's home directory, I remember now, reading the site…) So I could easily correct them using vi.

For the changes to take effect, you have to either logout/login or issue the following command

source ~/.bashrc

User … has used up 0.0% of their bandwidth and 121% of their allocated disk space

(Toegeschreven) Schijf(ruimte) loopt dus vol - nochtans, som van mails, databases en files is nog geen 3GB, en ik heb in principe 5GB ter beschikking.

Root cause: quarantined cache file - and solution

  • DirectAdmin: Extra Features > !cPGuard Security
    • FILENAME: !Boossy.DBCachePluginDB
    • CATEGORY: Virus File
    • VIRUS DESCRIPTION: {CPG}.php.onedrivephish.001.UNOFFICIAL

En dat zo meer dan 1000 keer. Dus 1000 keer 3MB is 3GB natuurlijk!

Eerst gerestored, maar uiteraard werd het bestand opnieuw in quarantaine geplaatst. Dus dan via het tandwieltje gewhitelist:
  • Whitelist Files: Boossy.DBCachePluginDB
Maar dat werkt niet. Reactie van Mirko:

Detecties van het type Virus File kunnen niet gewhitelist worden, alleen Suspicious Files kunnen gehitelist worden. Dit omdat Virus File’s (zeer) ernstige infecties bevatten, in dit geval een onedrive phish infectie. Ik raad dus aan om de hele website te scannen/na te lopen om te achterhalen waar dit probleem vandaan komt en zo het probleem met het schijfruimtegebruik ook op te lossen.

Een manuele scan van de wiki levert echter niets op:
  • TARGET: /home/.../domains/.../public_html/wiki
  • TESTED FILES: 20238
  • STATUS: DONE Success
Ik ben dan overgeschakeld naar een ander type caching. In de configure van de wiki:
  • Extensions kiezen & DONE Show expert options inschakelen
  • !DBCacheContrib
  • {DBCacheContrib}{Archivist}:
    • oude waarde: Foswiki::Contrib::DBCacheContrib::Archivist::Storable
    • nieuwe waarde: Foswiki::Contrib::DBCacheContrib::Archivist::Segmentable (zoals bij eXplio)
Voorlopig ziet dat er goed uit - maar de gecachete databestanden bevatten natuurlijk ook welhet woord wandraaif, wat volgens mij de oorzaak was waarom het bestand abusievelijk werd beschouwd als virus.

Things to check after configuration changes

  • are images still visible?
  • can attachments be downloaded?
  • can attachments be uploaded?

Login always required instead of once a day/month

Settings identical to foswiki settings at the office…

Security and Authentication category
  • Sessions tab
    • Use Client Sessions
    • Session Expiry
    • Cookie Expiry*
  • Login tab
    • Authenticated Scripts


niets toegevoegd, in tegenstelling tot wiki op kantoor
Tuning category
  • Cache tab
    • Enable Page-Cache
    • Cache Implementation
    • Cache Root Directory

Extensions category
  • !AutoRedirectPlugin
'context' => 'view',
'target' => 'WebHome',
'topic' => 'WelcomeUser',
'web' => 'Boossy'
tick enable
Extensions category
  • !HomePagePlugin
    • !SiteDefaultTopic
    • !GotoHomePageOnLogin

* enable Show expert options

Side effect was that I - again - got 406 errors:

was redirected to:

So I returned to the symlink of the bin directory:

ln -s bin app

In combination with the corresponding path settings in Foswiki Configuration :
  • General settings, Web URLs and Paths:
    • Script Url Path: /app
    • Script Url Path for View: /app/view

… but still requiring to login after every browser session!

So I used the quick and dirty way and modified the browser cookie using the !EditThisCookie browser extension:
  • .wiki.boossy.be | SFOSWIKISID
  • check the !HostOnly checkbox
  • uncheck the Session checkbox
  • click on the check icon at the bottom (save cookie settings)

See FwTest


modsecurity mod_security
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
This page was cached on 20 Apr 2021 - 13:02.