about summary refs log tree commit diff stats
path: root/src/event/server_events.c
Commit message (Collapse)AuthorAgeFilesLines
* Start implementing XEP-0084Michael Vetter2019-12-181-0/+3
| | | | So far we just subscribe and get the IDs.
* Use helper function to clean incoming messagesMichael Vetter2019-12-131-9/+9
| | | | | We might want to use utf8proc or something to normalize utf8 strings later?
* Add vim modelineMichael Vetter2019-11-131-0/+1
|
* Filter RTL unicode characters outMichael Vetter2019-11-131-0/+30
| | | | | | | | | | | | | | Gajim sends \u200E and \u200F for RTL. It is planned that Gajim stops doing this and uses some GTK feature to get the same result. However users expressed the whish that we filter out such characters in incoming messages before displaying them to make Profanity more robust. I'm still not sure whether I like the solution because it means a lot of allocating/deallocating upon every new message. Fix https://github.com/profanity-im/profanity/issues/1220
* Don't override ProfMessage Id with origin-idMichael Vetter2019-10-311-1/+1
| | | | | | | | | | Profanity sends the same value for both. Other clients might not. Safe both since we could need them later. Once we implement Last Message Correction we will need the regular id. If we override it with origin-id and another client chooses to not use the same value for id and origin-id then we can't interpret the id sent with the LMC request correctly.
* Two carbon logging changesMichael Vetter2019-10-291-27/+38
| | | | | | | | | | | | | Add resourcepart to the outgoing carbon that is logged, so we use the correct filenames for MUC PMs. Dont log incoming carbons of MUC PMs as a workaround to faulty server behaviour. See https://wiki.xmpp.org/web/Multi-Session_Nicks#Private_Messages under 'Client-side workaround behavior'. Regards https://github.com/profanity-im/profanity/issues/1214
* Also log sv_ev_delayed_private_messageMichael Vetter2019-10-291-0/+1
|
* Actually log MUC PM messagesMichael Vetter2019-10-281-1/+2
| | | | | | | | | | If I'm not mistaken MUC PMs have not been logged at all if there was no other client sending carbons. This should add MUC PM logging functionality. We still need to make sure carbons log to the same file. Regards https://github.com/profanity-im/profanity/issues/1214
* Fix which message we want to logMichael Vetter2019-10-191-5/+3
|
* Move message sent by us logic in own functionMichael Vetter2019-10-181-12/+4
|
* sv_ev_room_message: log in all cases if not our clientMichael Vetter2019-10-181-14/+13
| | | | Forgot to check what happens if the length is <= 10.
* sv_ev_room_message: check if message->id is not NULLMichael Vetter2019-10-181-1/+1
|
* Add connection_get_profanity_identifier stubMichael Vetter2019-10-181-1/+1
| | | | And move defintion to xmpp.h
* Log incoming MUC messages if origin-id sais they dont come from usMichael Vetter2019-10-181-2/+20
| | | | Regards https://github.com/profanity-im/profanity/issues/1201
* Don't log own messages on incoming MUCMichael Vetter2019-10-061-4/+7
| | | | | | | | | | | | | | `sv_ev_room_message()` called `groupchat_log_msg_in()` to log all incoming MUC messages. `cl_ev_send_muc_msg()` calls `groupchat_log_msg_out()`. So messages sent by the user himself was logged two times. Filter the incoming messages and only log the ones not from our occupant jid/nick. Fix https://github.com/profanity-im/profanity/issues/1201
* Log outgoing carbons instead of incomingMichael Vetter2019-10-041-4/+4
| | | | | | | | Incoming carbons are logged as normal message already. So we had this logged twice but didn't log outgoing carbons, send from our account but by another client, at all. Fix https://github.com/profanity-im/profanity/issues/1181
* Log 1:1 messages from other clients also to fileMichael Vetter2019-09-041-0/+4
| | | | | | Carbons where not logged so far. Fix https://github.com/profanity-im/profanity/issues/1181
* Improve sv_ev_roster_received() last activity checkMichael Vetter2019-08-021-11/+9
| | | | | We don't need to do all the timing stuff if last activity is disabled anyways.
* Don't print subscribed message if contact is already in rosterMichael Vetter2019-08-011-2/+6
| | | | | | | | | | | This occured with a user running Cisco Jabber. It seems this server sends repeated presence subscribed stanzas. And although I find this strange according to RFC this seems to be ok. So let's filter them and only display in the console output and to the log. But don't open seperate windows. Fix https://github.com/profanity-im/profanity/issues/1165
* Show MUC history on intentional reconnectMichael Vetter2019-07-031-7/+5
| | | | | Small bug caused by 13675fb and ce5a4ed. Fix https://github.com/profanity-im/profanity/issues/1142
* Fix handling of encrypted carbonsPaul Fariello2019-06-211-25/+57
|
* Rename prof_message_t into ProfMessagePaul Fariello2019-06-201-10/+10
|
* Add prof_message_t to wrap all message attributesPaul Fariello2019-06-201-118/+127
| | | | | | | Probably missing copy of body to plain in carbon and privmessage. Only covers the incoming message path because goal is OMEMO decryption of untrusted message. Cover some of the log functions but not all.
* Use flags in xmmp/message.c for encryption and trustPaul Fariello2019-06-201-5/+5
|
* Add myself to copyrightMichael Vetter2019-06-171-0/+1
| | | | Like discussed with James.
* Merge pull request #1110 from profanity-im/feature/704-ui-behaviour-reconnectMichael Vetter2019-06-111-2/+32
|\ | | | | Feature/704 ui behaviour reconnect
| * Safe last MUC message timestamp per MUCMichael Vetter2019-06-111-8/+7
| | | | | | | | | | | | After pasis review of my code he thinks it's better to safe the timestamp per MUC so we can account for some problems that could occur with timing.
| * Only show MUC subject on first connectMichael Vetter2019-06-051-1/+1
| | | | | | | | | | | | For #704 we don't show the room history upon reconnect. Now we also don't show the room subject in the channel upon re-established connection.
| * Reduce timestamp call when saving last muc messageMichael Vetter2019-06-051-12/+13
| | | | | | | | Let's test for mucwin earlier.
| * Only print room history for new messages upon reconnectMichael Vetter2019-06-051-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If re-establish a connection don't print the room history again. In case there there happened nothing at all since we got the room history on the last connection. And in case there were no new messages during the time we have been disconnected. Instead of printing the room history again we now print 'Re-established Connection'. This adds a bit of overhead since we save the timestamp upon every MUC message. See: https://github.com/profanity-im/profanity/issues/704
* | Rejoin all MUCs on reconnectMichael Vetter2019-06-101-5/+3
|/ | | | Should fix https://github.com/profanity-im/profanity/issues/1120
* Create seperate function for disconnect cleanupMichael Vetter2019-05-191-13/+2
| | | | | Duplicate code in client_events.c and server_events.c. Let's have events/common.c and a function containing that code.
* Fix ifdef guard (should have been OMEMO)Michael Vetter2019-05-061-1/+1
|
* Reset things on connection lossMichael Vetter2019-05-061-0/+5
| | | | | Remove the windows, clear tls certs, clean omemo. Regards https://github.com/profanity-im/profanity/issues/1089
* Merge pull request #1063 from paulfariello/hotfix/presence-before-rosterMichael Vetter2019-04-171-0/+1
|\ | | | | Handle presence received before roster
| * Handle presence received before rosterPaul Fariello2019-04-171-0/+1
| | | | | | | | | | | | | | | | | | | | Presence of contact not found in roster are filtered out. But sometimes roster is received after a first few presences. We choose to store presences until we receive roster and then process this presences. Fixes #1050
* | Follow OMEMO policy even when opening window on message and carbon receptionPaul Fariello2019-04-171-0/+14
|/ | | | This should close #1052
* Try to start sessions with every jid in rosterPaul Fariello2019-04-101-0/+4
|
* Wait for discovery end to publish omemo devicelist and bundlePaul Fariello2019-04-101-0/+8
| | | | Add sv_ev_connection_features_received for that purpose
* Rework MUC reflected message filteringPaul Fariello2019-04-101-7/+3
| | | | | | | | | Reflected messages can't be filtered by nick only otherwise you might ignore messages comming from you on another devices. Consequently we maintain a list of sent messages id in mucwin. To be sure the id will be correctly reflected we use the origin-id stanza.
* Ensure encrypted carbon of own message are marked as encryptedPaul Fariello2019-04-101-2/+38
|
* Log and print outgoing encrypted messagePaul Fariello2019-04-101-11/+55
|
* Handle decrypted OMEMO messages as suchPaul Fariello2019-04-101-4/+90
|
* Add support for encrypted carbonPaul Fariello2019-04-101-1/+1
| | | | Fix {signed,}_pre_key store
* Add OMEMO identity materials long term storagePaul Fariello2019-04-101-0/+8
|
* Follow normal workflow for OMEMO message receptionPaul Fariello2019-04-101-1/+1
| | | | | | We try to decrypt all messages, if it's successful we use sv_ev_incoming_message even for OMEMO messages. We pass an OMEMO boolean to let UI be aware that message were encrypted.
* Redraw screen after entry of PGP secret keyMichael Vetter2019-02-201-0/+10
| | | | | | | | | | | | | | | | | | | | | | After specifying the PGP key ID with pgp.keyid within the accounts file on startup profanity asks for the secret key passphrase. It then doesn't redraw the screen, leaving it in an odd looking state. This probably only happens with pinentry-curses since it draws in screen. We need this fix for cli only environments. Fixes https://github.com/boothj5/profanity/issues/906 reported by Bob Mottram. Based on https://github.com/boothj5/profanity/pull/908 by Bob Mottram Bob removed his GitHub account, so GitHub created a ghost placeholder user for him, which unfortunately makes it impossible to cherry-pick this commit. To more or less preserve authorship I added him as co-author. Commit picked and message edited by jubalh. Co-authored-by: Bob Mottram <bob@freedombone.net>
* Update copyright to include 2019Michael Vetter2019-01-221-1/+1
|
* Merge pull request #926 from msantos/null-pointer-dereferenceMichael Vetter2018-07-301-6/+8
|\ | | | | server_events: fix potential NULL pointer deref
| * server_events: fix potential NULL pointer derefMichael Santos2017-04-121-6/+8
| |
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-28 23:54:39 +0000