| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
- the block domain option is in a drop down of the block button
- when blocking the domain, the "Blocked domain" button appears
and block button disappears and vice versa.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most Certificate Authorities don't support issuing X.509 certificates for onion
sites. However, it can still be useful to provide a certificate over Tor in
some circumstances, for instance to tie your alphanumeric Tor address to your
site's main identity.
Therefore, many Tor services provide self-signed certificates. This is OK,
since the onion service itself guarantees that you are connecting to the entity
you think you are.
Dino already allows self-signed certs when communicating over Tor (see
81a5505). However, the same exception does not exist yet for HTTP uploads and
downloads - causing these to fail over Tor.
Therefore, in this commit, we add the same exception for uploads/downloads, by
passing the host of the upload/download urls to the already existing invalid
certificate connection handler.
Note that this handler only allows certificates with type
TlsCertificateFlags.UNKNOWN_CA. This means the certificate of your server must
also include the onion http upload and download URLs in its certificate -
otherwise, the file transfer will fail with TlsCertificateFlags.BAD_IDENTITY.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Self-ping with server-given roomnick (#1467)
XEP-0045 describes how a server can modify a user's roomnick when joining a
room. To do this, it assigns status code 210, and sets the "from" attribute to
a JID with thew newly assigned nickname when sending the user's presence back
to the client.
This is used in IRC gateways such as biboumi. Since you can only have one nick
per IRC server, if you try and join multiple IRC-bridged MUCs on the same IRC
server, it will modify your nick to match the existing one you have on that
server.
Currently, when Dino performs a self-ping after joining a room, it uses the
nick that the client first requested, instead of the nick returned from the
server. This can lead to incorrect self-pings being sent out (until the client
is restarted, and populates mucs_todo correctly). This happens because it adds
the requested Jid to mucs_todo, before getting the given nick from the server.
Therefore, this commit adds the jid that has been given from the server
instead. If there is any error in requesting to join the MUC, it adds the
requested nick, to match existing behaviour and allow the request to be retried
via future self-pings.
fixes #1467
* Minor coding style changes
---------
Co-authored-by: fiaxh <git@lightrise.org>
|
| | |
|
| |
|
|
|
| |
- Only show avatar remove button if one is set, fixes #1589
- Only show account picker if user has more than one account
|
| | |
|
| |
|
|
|
| |
should close #139
- adds svg dino-status-offline.svg
|
| |
|
|
| |
fixes #1592
|
| | |
|
| | |
|
| |
|
|
| |
determining of private MUCs
|
| | |
|
| | |
|
| |
|
|
| |
The suggestion is to not use title case which we did before.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While doing testing I noticed that skeletons were being leaked, and
eventually tracked it down to the timer that updates the time label
closing over "this" and then keeping the reference alive, potentially
for 24 hours.
I noticed a few other places in the code doing some version of this, and
one of them had the "static and weak pointer" approach, which I pulled
out into a util class. Now, we still have to make sure we're passing it
a static method instead of a lambda, as that would also close over
"this" and render the whole thing useless, but at least most of the
annoying parts live in the util class now.
Also the call_widget version was doing a weird thing where it was
removing itself, but then returning "true"? I'm not sure what that
accomplishes, because returning "false" means to not run this again. So
I think my new version is the same in practice, but simpler...
There are other timeouts in the code that I briefly looked over, but all
of them seemed to be relatively short hard-coded durations, so I left
them alone.
But if any of them are long-lived, it's possible they could also benefit
from this class in the future.
Closes #1480
Co-Authored-By: Marvin W <git@larma.de>
|
| |
|
|
|
| |
This should never happen in practice, but now we will correctly display
if a call has encrypted audio, but unencrypted video, or vice-versa.
|
| |
|
|
| |
Taken from https://github.com/GNOME/vala-extra-vapis/commit/6b8a3e4faaabc462f90ffcb0cf0f91991ee58077
|
| |
|
|
|
|
|
|
|
| |
- fixes https://github.com/dino/dino/issues/1542
- more consistent with
https://xmpp.org/extensions/xep-0045.html#enter-subject:
"Note: In accordance with the core definition of XML stanzas,
any message can contain a <subject/> element; only a message that
contains a <subject/> but no <body/> element shall be considered a
subject change for MUC purposes."
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
- fixes #1308
|
| |
|
|
|
| |
Co-authored-by: Alexandre Jousset <mid@gtmp.org>
Co-authored-by: Aidan Epstein <aidan@jmad.org>
|
| |
|
| |
fixes #1042
|
| | |
|
| | |
|
| | |
|
| |
|
| |
fixes #1508
|
| |
|
|
|
|
|
| |
* Fix for ejabberd XMPP server 'infinity' http upload file size announce
- fixes https://github.com/dino/dino/issues/1222
* Update 0363_http_file_upload.vala
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* Start conversation if closed when receiving an audio or video call
* Fix starting conversation on new calls, move setting conversation.last_active
---------
Co-authored-by: fiaxh <git@lightrise.org>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
