Item13989: When you disable guest sessions you also disable all registration and reset of password.

I tried running my public Foswiki on lavrsen.dk with guest sessions turned off

I have so much load on the server - so much that the fans spin up at night so I can hear it in the other room. And the reason is mainly all the darn bots that milk the site.

And what takes power is handling 10000-100000 garbage sessions.

Turning the sessions off for one day and the site is faster - and the server is silent and can easily deliver the page views - also for the bots.

But - I got complaint emails. People could not register.

So we have a great experimental feature which deserves to be the default way of doing things. But it needs some work.

I have tried to put this code in LoginManager.pm

    if ( $session->{request}->path_info() =~ /(Registration)|(ResetPassword)/ ||
         $session->{request}->action() eq 'register' || 
         $session->{request}->action() eq 'resetpasswd' ) {
            $guestSessions = 1;
    }

two places at the start of the subs loadSession and userLoggedIn. They are the only places we use the configure setting so I decided that would be the easy place to attack the problem

The code ensures that any topic with Registration in the name and the ResetPassword topic creates a session. And then we need to carry over the session to the resulting register or resetpasswd script. For now it works. You still get some dummy session files from bot if you redirect 401s to UserRegistration. I will probably change that in the Apache conf.

Even with those I still only have 22 sessions after several hours. Before I had several 1000s per hour! It gives a significant performance boost.

My fix would not be the final solution I guess. Issue would be - what if you have a registration topic name which is not a Registration named topic. Yet another configure script? That will work but - ah - I'd prefer something that "just works". Any suggestions?

-- KennethLavrsen - 24 Feb 2016

Currently the Foswiki session is created before the web / topic is parsed out of the query path. I don't see any reason not to move the initialization:

    # Load (or create) the CGI session
    $this->{remoteUser} = $this->{users}->loadSession($defaultUser);

down a couple of lines further, so that the web and topic has been established. This would eliminate the need to parse the path_info() in the LoginManager, which would fail if the web/topic was provided by the query params.

I can't see any way of making this universal without configuring a list of topics, or a regex to match topics. For actions, we might consider adding a flag into the switchboard - sessionRequired > 1.    For the matching of topics,  how about: =$Foswiki::cfg{Session}{TopicsRequireGuestSessions} = '(Registration|ResetPassword)$';

-- GeorgeClark - 14 Mar 2016

There is a bit of an issue here. When a page uses ajax helpers, for ex. user registration verifies that the WikiName does not exist, the ajax request causes the session to be cleaned up and strkeone then fails when the registration is submitted.

On Foswiki 2.1. the Ajax helper for registration - UserRegistrationParts - also needs to preserve sessions.

-- GeorgeClark - 16 Mar 2016

I've attached a patch that implements these changes on a 2.1 system.

patch -p2 < patchItem13989

• patchItem13989: Patch for guest session support

-- GeorgeClark - 17 Mar 2016

Updated patch attached. The session is now sticky. Guests don't get one by default, but if they do, it sticks. This way, ajax requests don't kill the session. This also removes the exceptions for the register and reset password scripts. As long as the calling page gets a session, they will have it.

-- GeorgeClark - 18 Mar 2016

The patch is now running on Foswiki.org. cgisess_ files went from 17-28 thousand down to 125.

-- Main.GeorgeClark - 31 Mar 2016 - 23:00

Commenting is disabled while not logged in