[BlueOnyx:17087] Re: 5208R Upgrades and question

[Michael Stauber]

Hi Michael,

> On the New GUI the default for everything is 10 which is lower than the
> old GUI. Where in the new code is that 10 selected?
> I understand if you have reasons for keeping it low but I want to be able
> to manually change it myself.
> 
> I found the answer myself.
> 
> It is in /usr/sausalito/ui/chorizo/ci/application/views/pluginsmin.php

Correct. The default is 10 as that's what seems to work best with most
screen resolutions. Additionally the pagination, "Show X entries"
pulldown and the search refresh the content without page reloads. So I
just left it at 10 which was the default for the Adminica theme. But
sure, you can change it in pluginsmin. Until the next base-alpine update
overwrites it.

> Ok so for the next item I want to change the login timeout. I leave a
> browser open and I hate that I always have to login again when a client
> calls.
> 
> There is "protected $_csrf_expire                 = 7200;" in the file
> /usr/sausalito/ui/chorizo/ci/system/core/Security.php
> Is this the right thing to change for the login cookie?

Not really.

There are a couple of things that play a role here. Let me walk you
through them one by one.

When you check
/usr/sausalito/ui/chorizo/ci/application/config/config.php you will see
that the csrf_protection is disabled. I had to do this or the API
wouldn't work. Can't really turn the csrf_protection off selectively.
It's either on or off for the whole GUI.

The GUI login form is this script:

/usr/sausalito/ui/chorizo/ci/application/modules/base/login/controllers/login.php

When you authenticate successfully against the GUI login form it sets a
number of cookies. The two important ones are the cookies "loginName"
and "sessionId".

They are set this way:

setcookie("loginName", set_value('username_field'), time()+60*60*24*365,
"/");

setcookie("sessionId", $sessionId, "0", "/");

So "loginName" is kept for one year and "sessionId" expires at the end
of the browser session.

Whenever you load a GUI page, these two cookies are checked and are
passed on to CCEd via the command "AUTHKEY $loginName $sessionId"

CCEd then reports back "201 OK" if the username and sessionId are still
valid. Or it reports back "401 FAIL" if they are not (or no longer) valid.

And there is actually the catch:

The cookie that PHP sends to your browser does only expire if you close
the browser or voluntarily end the session via a logout, right? So that
should actually be good enough to not make it expire while you're on the
phone. So there is more to that:

It is CCEd that actually decides if your browser-cookie is still valid,
or if it has expired due to inactivity. Whenever you load another GUI
page and do CCEd transactions, the validity gets extended.

How long the allowed period of inactivity actually can be is defined here:

http://devel.blueonyx.it/trac/browser/BlueOnyx/5207R/utils/cce/include/sessionmgr.h

See line 14:

#define SESSION_TIMEOUT         (60 * 60)

If I'm not mistaken that's 60 minutes?

That's then referenced in the sessionmanager of CCEd:

http://devel.blueonyx.it/trac/browser/BlueOnyx/5207R/utils/cce/sessionmgr/src/sessionmgr.c

And of course in CCEd itself:

http://devel.blueonyx.it/trac/browser/BlueOnyx/5207R/utils/cce/server/src/main.c

So ... the timeout is a hard-coded default of CCEd. But the semi-sort-of
good news is: It can be overridden by a command line switch:

[root at 5208r ~]# /usr/sausalito/sbin/cced -h
Cobalt Configuration Engine (CCE) version 0.99.1Copyright (c) 1999,2000
Cobalt Networks, Inc. - Copyright (c) 2014 Team BlueOnyx, BLUEONYX.IT
usage: /usr/sausalito/sbin/cced [options]
  options:
    -v          display version info and exit
    -c          set global cce dir
    -d <num>    set debugging mask
    -nd         do not daemonize
    -nf         do not fork (allow one client)
    -nh         do not use handlers
    -ro         run read-only (implies -nh)
    -st <secs>  set session timeout
    -V          verbose (errors to stderr)
    -nl         no logging to syslog
    -nt         stop txn library support
    -tf         make all txns fail

So if you start CCEd with "-st <secs>" that would override it. The
downside there is: The init script for 5207R/5208R has no provisions for
this.

In /etc/init.d/cced.init we're simply firing up cced this way:

daemon /usr/sausalito/sbin/cced

If you change the two instances of "daemon /usr/sausalito/sbin/cced" to
this ...

daemon /usr/sausalito/sbin/cced -st 7200

... if you wanted to extend it to 120 minutes.

Two things here: Does it really take one hour of inactivity to boot you
out of the GUI? Actually I don't know. I never measured it with a
stopwatch. It appears to happen sooner than 60 minutes, right?

Now lets go back to our PHP configuration: /etc/admserv/php.ini

As far as the PHP session stuff is concerned it runs off defaults. Which
means (according to phpinfo() on a 5208R) it has this:

session.cache_expire		180
session.cookie_lifetime		0
session.gc_maxlifetime		1440

I just looked them up here:

http://php.net/manual/en/session.configuration.php

The "cache_expire" is harmless. The "cookie_lifetime" set to "0" just
means: Expires on end of browser session. Like closing a tab or the
whole browser.

But the "session.gc_maxlifetime" is the kicker here. It considers a
cookie as "garbage" if it's older than 1440 seconds (24 minutes). And I
think 24 minutes sounds just about right. It feels like the GUI throws
you out after 24 minutes or thereabouts, right?

So this should be easy to check. Just edit /etc/admserv/php.ini and
change ....

session.gc_maxlifetime = 1440

.... to ...

session.gc_maxlifetime = 3600

... to make it last for an hour. Restart AdmServ and see if it lets you
stay for 25-59 minutes of inactivity. If you need an expiry longer than
an hour, then you'll also have to modify the init-script of CCEd and
have to set the longer expiry via the "-st" switch as mentioned above.

I think that should explain how the session cookies work. But as you can
see: It's a bit of guesswork from my end as well, as that is stuff that
I just "inherited" and never messed with.

If it ain't broken, don't fix it. :p

-- 
With best regards

Michael Stauber