Make the session portable and independent of paths, code, classes and php version

[vtsykun]

Currently auth session is storage together with all serialized php data (cache, peer cache, class names, full paths). Due to this session stop working after changes the user namespace code. For example, after rename event handler class, I need to login again.

How to reproduce

1) create event handler - AaaHandler

AaaHandler::startAndLoop('session.madeline', $settings);

2) rename AaaHandler to AaaHandler2

Actual result

AssertionError: Please make sure the App\AppHandler class is in scope, or that the event handler is running (in a separate process or in the current process). in /app//vendor/danog/madelineproto/src/Serialization.php:190
Stack trace:
#0 /app//vendor/amphp/amp/src/functions.php(34): danog\MadelineProto\Serialization::unserialize()
#1 /app//vendor/revolt/event-loop/src/EventLoop/Internal/AbstractDriver.php(425): Amp\{closure}()
#2 /app//vendor/revolt/event-loop/src/EventLoop/Internal/AbstractDriver.php(562): Revolt\EventLoop\Internal\AbstractDriver->invokeMicrotasks()
#3 [internal function]: Revolt\EventLoop\Internal\AbstractDriver->Revolt\EventLoop\Internal\{closure}()
#4 /app//vendor/revolt/event-loop/src/EventLoop/Internal/AbstractDriver.php(498): Fiber->start()
#5 /app//vendor/revolt/event-loop/src/EventLoop/Internal/AbstractDriver.php(537): Revolt\EventLoop\Internal\AbstractDriver->invokeCallbacks()
#6 [internal function]: Revolt\EventLoop\Internal\AbstractDriver->Revolt\EventLoop\Internal\{closure}()
#7 /app//vendor/revolt/event-loop/src/EventLoop/Internal/AbstractDriver.php(94): Fiber->start()
#8 /app//vendor/revolt/event-loop/src/EventLoop/Internal/DriverSuspension.php(117): Revolt\EventLoop\Internal\AbstractDriver->Revolt\EventLoop\Internal\{closure}()
#9 /app//vendor/amphp/amp/src/Future.php(251): Revolt\EventLoop\Internal\DriverSuspension->suspend()
#10 /app//vendor/danog/madelineproto/src/API.php(307): Amp\Future->await()
#11 /app//vendor/danog/madelineproto/src/API.php(194): danog\MadelineProto\API->connectToMadelineProto()
#12 /app//vendor/danog/madelineproto/src/EventHandler.php(77): danog\MadelineProto\API->__construct()
#13 /app//test1.php(28): danog\MadelineProto\EventHandler::startAndLoop()

I need to login again after the code changes.

Also I got an error if change path, switch php version

Expected result

The cache must be splitted: on auth session data and other runtime cache. session data must be portable and must not contains reference on user namespace class names, phpversion, full paths etc.

Other serialized data can be safely deleted. rm -rf .session.madeline/cache

└── /var/www/
    └── .session.madeline/
        ├── cache/
        └── private_session

[danog]

This is not a good idea, because an event handler class is not something you should be able to rename: it may contain important persistent data, for example if you use properties + __sleep to persist data to the session, and renaming it means loosing it.

It is possible to add some complex logic which will move properties to the new object if the class is renamed, but it is simply not worth the effort.

[vtsykun]

The idea is that when changing the code I don’t have to log with enter password, code and phone in every time. I want to delete persist runtime data/cache with keeping login session. How I can do it?

[danog]

MadelineProto's session folder contains a large amount of information needed for MadelineProto to work.

This information can be stored:

• In RAM (default), saved to the session files every 30 seconds and on shutdown.
• On MySQL/Postgres/Redis, according to the database settings ».

The default in-RAM storage is the fastest, but obviously uses much more memory than the MySQL/Postgres backends.

The session data consists of multiple databases, used to greatly improve performance and reduce flood waits through caching.

Some of these databases optionally be disabled according to the database settings », in order to use less RAM/disk space: however, this usually leads to performance issues, increased flood waits (& bans) and disabled MadelineProto features, so please avoid tweaking the database configuration unless absolutely necessary.

• Authorization & session keys to identify and communicate with Telegram's MTProto servers.

• Peer database, containing the access hash (needed to interact with users and chats via MTProto) and other information (name, type & other info returned by getInfo/getFullInfo) about chats and users met during normal operation.

  Without the access hash handled automatically by MadelineProto's peer database, you wouldn't be able to interact with users and chats by using their ID: for this reason, completely disabling the peer database is not allowed.

  However, through the database settings », the peer database can be optionally configured to only store the access hash+basic info, or just the access hash, without all the extra information: this will break getInfo/getFullInfo and other MadelineProto features that rely on it, like the event handler.

• Username database, used by MadelineProt to map usernames to IDs for quicker @username lookups.

  Through the database settings », the username database can be optionally disabled, completely disabling and breaking username resolution in all MadelineProto methods.

• Min database, containing min peer location information.

  MadelineProto uses the min database automatically to populate the peer database when working with min peers.

  Through the database settings », the min database can be optionally disabled, which can lead to PeerNotInDbException exceptions when working with certain peers.

• File reference database, containing location information about files

  MadelineProto uses the file database automatically to populate expired file references when downloading and resending files.

  Through the database settings », the file reference database can be optionally disabled, which can lead to FILE_REFERENCE_* errors when working with files.

• Secret chat database, containing secret chat info&messages.

• Other persistent information (i.e. the event handler instance, which is not a cache, i.e. not data that can be easily forgotten)

This session structure is very similar to the structure of official graphical clients: all official clients use the same databases in order to work, and sometimes have even more databases for other purposes.