We are moving our forum in GitHub Discussions. For questions about Phalcon v3/v4 you can visit here and for Phalcon v5 here.

Phalcon session to handle both normal session and SESSID in http header

Phalcon session to handle both normal session and SESSID in http header

We are developing a system that both serves as regular web platform and also serves an API for Sencha based iOS/Android App’s.

For this we need to modify Phalcon's regular session service, if anyone has an idea to do this ?

Our session implementation in the DI:

use Phalcon\Session\Adapter\Redis as RedisSession;

$di->setShared('session',function() use ($di) {
    $session = new RedisSession([
        'uniqueId'   => '',
        'host'       => '',
        'port'       => '',
        'persistent' => '',
        'lifetime'   => '',
        'prefix'     => '',
    return $session;

The standard session gets the Session ID from the cookie via the http header, like the usual http response headers from a browser:

Host: somesite.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: PHPSESSID=c1755e44a3f3265e1ec6f0d01dc10177

But the Sencha App will not send the session ID in a cookie, but directly in the http headers, as 2 extra fields, where device-token holds the session ID:

device-token: c1755e44a3f3265e1ec6f0d01dc10177

So the big queston is:

How do we get Phalcon to accept both normal PHP Session id like from:

$headers = getallheaders();

… and if it is not found there, then get the session ID from:


Anyone has an idea ?

Why in the world you would do it like this? It's better to setup Micro app which will share services and the rest config of your main app and use it to serve full API to those mobile apps.

So just bootstrap Micro with same services container etc.

Also, for sure you can override session service if you want, but IMHO that's dirty solution.


Thanks Jonathan, you are right, was a dead-end on that project. On another similar project, we ended up with a multi-module solution. Serving public site, internal system and API from 3 different modules/domain prefix/namespaces. For the mobile API we keep state using Json Web Tokens ... works realy well... All plays super nicely, Phalcon is a very, very cool framework...