- no '-c': same behavior as before, do not connect the profile
- '-c' with not following value: autoconnect and use the default value '' as profile password
- '-c' with a following value: autoconnect and use that value as profile password
Note that previous scripts may not work. For example, even if the profile password for "test1" is empty:
jp disco -p test1 -c contact@host.net
must be changed to:
jp disco -p test1 -c -- contact@host.net
Otherwise, argparse will think that "contact@host.net" is the password and that the target JID is missing.
/!\ This changeset updates the database version to 2 and modify the database content!
Description:
- new parameter General / Password to store the profile password
- profile password is initialized with XMPP password value, it is stored hashed
- bridge methods asyncCreateProfile/asyncConnect takes a new argument "password" (default = "")
- bridge method asyncConnect returns a boolean (True = connection already established, False = connection initiated)
- profile password is checked before initializing the XMPP connection
- new private individual parameter to store the personal encryption key of each profile
- personal key is randomly generated and encrypted with the profile password
- personal key is decrypted after profile authentification and stored in a Sessions instance
- personal key is used to encrypt/decrypt other passwords when they need to be retrieved/modified
- modifying the profile password re-encrypt the personal key
- Memory.setParam now returns a Deferred (the bridge method "setParam" is unchanged)
- Memory.asyncGetParamA eventually decrypts the password, Memory.getParamA would fail on a password parameter
TODO:
- if profile authentication is OK but XMPP authentication is KO, prompt the user for another XMPP password
- fix the method "registerNewAccount" (and move it to a plugin)
- remove bridge method "connect", sole "asyncConnect" should be used
if %(profile)s is used in log_fmt, SàT try to find profile value using introspection. This is for debugging purpose only, *DO NOT* use in production. This key don't work (yet ?) with standard backend, and will not work in every frontend.
- configuration is now done with classes, so inheritance is possible
- twisted backend now use twisted log methods
- log not produced by SàT directly in twisted backend are captured by an observer (twistedObserver) and sent back to SàT logging chain, with the "twisted" logger.
- \\default output use normal twistd output, except in debug mode where it add an stdout output in addition to the log file.
- when log_colors = True, colors are enabled only where it's possible (tty out), when log_colors=force colors are always enabled.
- fixed some bad log.xxx calls
- formatting is inspired from, and use when possible, standard logging. "message", "levelname", and "name" are the only format managed, depending on backend more can be managed (standard backend formats are specified in official python logging doc)
- name filter use regular expressions. It's possible to log only plugins with SAT_LOG_LOGGER="^sat.plugins". To log only XEPs 96 & 65, we can use SAT_LOG_LOGGER='(xep_0095|xep_0065)'
- output management use a particular syntax:
- output handler are name with "//", so far there are "//default" (most of time stderr), "//memory" and "//file"
- options can be specified in parenthesis, e.g. "//memory(50)" mean a 50 lines memory buffer (50 is the current default, so that's equivalent to "//memory")
- several handlers can be specified: "//file(/tmp/sat.log)//default" will use the default logging + a the /tmp/sat.log file
- if there is only one handler, it use the file handler: "/tmp/sat.log" is the same as "//file(/tmp/sat.log)"
- not finished, need more work for twisted and basic backends
- variable change logs behaviour, so far only level and colors are implemented
- configuration use log_[name], for example you can put log_level=debug in sat.conf (section [DEFAULT]) to see all levels
- environment variables use SAT_LOG_[NAME]: e.g. SAT_LOG_LEVEL=debug
- colors can be true, false or force to force colors even if stdout is not a tty
- added a core.log module
- 3 backends can be used: basic, standard (python's logging module) or twisted
- colors can be used
- the module has been made to be used by frontends, it should work in exotic environments like pyjamas
- logging basic configuration is now made in sat.tac
- core.log configuration is inspired from python standard logging, and use it when possible
- getLogger should be used the same way as for standard logging
