Trixbox, PHP Sessions and FOP2

[nicolas]

[h]Trixbox, PHP Sessions and FOP2[/h]

All the popular Asterisk distributions, like Trixbox, Elastix, PBX in a Flash, etc, include a basic LAMP stack (Linux, Apache, Mysql and PHP).

In order for the phonebook and some extra FOP2 features to work, PHP sessions must be working. By default, the standard PHP configurations will store a cookie on your browser with the session id, so you also must allow cookies to be written.

Trixbox includes a LAMP stack, but in its latest release also includes a PHP module to store sessions in memory using memcached. That is really nice and dandy, unfortunately, they forgot to enable the memcached daemon in the boot process. So, in a standard trixbox installation, PHP sessions are broken.

Everything will appear to be working fine, except when you try to open the FOP2 phonebook or any other section that requires php sessions enabled. You will see an error like:

"No way"

(unpolite message from FOP2 versions 2.20 or older) or:

"You do not have permissions to access this resource"

In order to fix this, you have two options:

1. Start the memcache daemon and enable it at boot

2. Disable the memcache module and use the standard file based php sessions

As I have seen the memcached based sessions failing for no apparent reason, my suggestion is to disable the memcache module. For doing that, you can edit the file /etc/php.d/memcache.ini and comment out ALL lines in that file:

; Enable memcache extension module
;extension=memcache.so

; Options for the memcache module

; Whether to transparently failover to other servers on errors
;memcache.allow_failover=1
; Defines how many servers to try when setting and getting data.
;memcache.max_failover_attempts=20
; Data will be transferred in chunks of this size
;memcache.chunk_size=8192
; The default TCP port number to use when connecting to the memcached server 
;memcache.default_port=11211
; Hash function {crc32, fnv}
;memcache.hash_function=crc32
; Hash strategy {standard, consistent}
;memcache.hash_strategy=standard

; Options to use the memcache session handler

; Use memcache as a session handler
;session.save_handler=memcache
; Defines a comma separated of server urls to use for session storage
;session.save_path="tcp://localhost:11211?persistent=1&weight=1&timeout=1&retry_interval=15"

After that, restart your web server:

[fixed]service httpd restart[/fixed]

By now you should have file based php sessions working on your Trixbox setup.

[stevensedory]

So, like mentioned in this post, I see "You do not have permissions to access this resource" on the Call History plugin (so it shows on the front panel) often, but if I log out and back on, it will usually correctly show the call history.

I don't have a memcache.ini file in the php.d folder. How can I apply option 1: "Start the memcache daemon and enable it at boot" instead?

[nicolas]

If it works 'sometimes' then I do not think you have issues with memcache or sessions, otherwise it would fails always. I do not remember how the memcache service was called in trixbox, you can enable for starting at boot with

chkconfig memcache on

(name "memcache" could be "memcached" or a different name).

[stevensedory]

So I've let this go on for a long time. We still get the error "You do not have permissions to access this resource".

I am on CentOS with FreePBX. There isn't a file on the server named memcache*

How would you recommend I go about fixing the issue based on this information?

[stevensedory]

Can we get some help on this please?

[nicolas]

My suggestion is to upgrade to the latest FOP2 version and latest version of any plugins. If you still have issues with php sessions, then you will have to check your web server error log file and see if you see any errors related to sessions and php. If your panel is not reachable from the internet, you can bypass the session security check directly in the code.. you can look at callhistorybsgrid.php file and comment the "die" lines.

It is really hard to give you a straight answer as session issues can vary greatly, depending on your linux distro, if packages were updated via yum or not, etc.

The latest FOP2 version will attempt to regenerate php sessions at short intervals and is more resilient to 'recover' from some issues (like premature expiration of sessions), but if you have broken php sessions, those have to be fixed directly on your server.

Best regards,

[stevensedory]

Thank you, I will make sure we're all up to date, and since we aren't accessible from the internet, comment out those lines if there's still an issue.