`/affiliation register` can now be used to register a nickname with a
MUC.
Tested with a server without forms. Couldn't find a server which
supports forms yet.
Implements https://github.com/profanity-im/profanity/issues/1210
Through asprintf() we can get rid of malloc() + sprintf().
Also we don't need to calculate the strlen() again since asprintf()
returns the bytes printes.
Only non UTF-8 characters. But that was true before already.
Main changes:
1. Attributes instead of tags
2. Read the optional <header> tags and send them in the HTTP PUT header:
* Authorization
* Cookie
* Expires
Co-authored-by: Martin Dosch <martin@mdosch.de>
Use the following options in `omemo_bundle_publish()`:
- "pubsub#persist_items" = "true"
- "pubsub#access_model" = "open"
The same options are also used in Gajim.
I've tested this on two different servers. The bundle was successfully
added as a new PEP node. Test cases:
1. Normal use on my main account
2. Log in into a fresh tesst account on a different server
3. `/omemo clear_device_list`. In this case, the client(s) may have to
be restarted.
Note: In `_omemo_bundle_publish_result`, there's a route that is taken
when the bundle publish stanza failed. In this case, the node is
configured manually, i.e. the access_model is set to 'open'. I have
manually tested this case, but this case didn't naturally occur for me.
Note: The option "pubsub#max_items=max" is REQUIRED for the bundle
publication, as per XEP-0384. However, this is not done in other clients
(I've checked the source code of Gajim and Conversations), and it is
also not supported by Prosody. Cf. <https://github.com/xsf/xeps/pull/988>.
Regards https://github.com/profanity-im/profanity/issues/1488
Actually I would have loved to see the stanza that caused the segfault
since I'm not entirely sure whether this actually means that we do
something wrong earlier on.
Right now I don't know why the to_jid should be empty.
Let's prevent the segfault for now and see whether we get further
bugreports later.
Segfaulting issue got introduced with dd566d8d56.
On every write to `chatlog.db` syslog throws
```
profanity: vfprintf %s NULL in "INSERT INTO `ChatLogs` (`from_jid`,
`from_resource`, `to_jid`, `to_resource`, `message`, `timestamp`,
`stanza_id`, `archive_id`, `replace_id`, `type`, `encryption`) SELECT
'%s', '%s', '%s', '%s', '%s', '%s', '%s', '%s', '%s', '%s', '%s' WHERE
NOT EXISTS (SELECT 1 FROM `ChatLogs` WHERE `archive_id` = '%s')"
```
in `/var/log/messages`. Checking for `NULL` except in the fields the DB
is expected to throw errors for, satisfies OpenBSDs security measures
