bfadbf0
fix the breakage of non-MMS messages from cd6e0df
Click to expand commit body
While maybe a bit awkward (as the conditional is left until the end of
the statement), this fix for a non-present 'media' element sure does
make for an elegant diff.
With this, the SGX works at least as well as at it did before cd6e0df
(i.e. as of d49bf12) but the MMS ("picture messaging") support added
in cd6e0df does still need some work as mentioned there. In
particular, we need to ensure that the media is accessible to the
user, which may necessitate us bringing back mpx-catapult in some form
(it was deleted in b1aabae).
Denver Gingerich
created
cd6e0df
move media handler into active block - no work yet
Click to expand commit body
Move the media handler code from the now-inactive 'mms' block (since
V2 messages don't have that type) into the new 'message-received'
block. While this does cause the user to receive the media message,
there are still at least two problems:
1. This commit breaks non-MMS messages (since 'media' is undefined).
2. Media messages are not delivered with the correct URL (needs mpx?).
Anyway, we know about these, but wanted to keep this commit short and
sweet so that changes to the actual media handler are separate from
the commit that merely moves the code from one place to another
without changes to the media handler code itself.
Denver Gingerich
created
d49bf12
suppress message delivery receipts for group texts
Click to expand commit body
Currently there is an interaction bug between this SGX and Cheogram
where Cheogram sends its "Instead of sending messages to cheogram.com
directly..." error if we naively send delivery receipts for group
texts. This might be related to us sending two separate delivery
receipts with the same ID, but it's still unclear exactly what the
issue is.
So until we solve the problem that causes us to not be able to send
delivery receipts to Cheogram, just turn off that functionality.
This functionality wouldn't work anyway since Cheogram does not yet
support subscription requests on porcelain JIDs, which means we can't
test delivery receipts in most clients (as they need a subscription
before they will enable receipts).
Denver Gingerich
created
b277759
first working message delivery receipts; tiny hack
Click to expand commit body
Delivery receipts (at least for single-recipient messages) now work
correctly with the V2 API. This was mostly simple changes (just
needed to change the deliveryState == 'delivered' check to instead be
type == 'message-delivered'), but did require a bit of a hack because
of the way we decided to determine the source and destination numbers
in d2e2d92 - there's probably a cleaner way, but we'll just go forward
with this quick fix for now, and do a better job of it later (which
may be needed anyway once we do (likely required) additional work for
multi-recipient message delivery receipts.
Denver Gingerich
created
3713283
fix incorrect split to add a limit; fixes 75d0c17
Click to expand commit body
We discovered this while testing message delivery receipts, which
fortunately included the word "Gajim" in the messages in our tests,
causing Goliath to bail with an HTTP 400 error, indicating bad JSON.
Which was correct, since we would only have been sending the JSON part
before the 'G' in Gajim, due to incorrectly failing to limit the
number of splits being done by the split that is fixed here.
That will teach me to parse JSON without a JSON parser, or not...
Denver Gingerich
created
90331bc
theoretically the first successful group text code
Click to expand commit body
Per https://wiki.soprani.ca/SGX/GroupMMS we have implemented the
protocol for receiving group texts. For now we hard-code
"cheogram.com", but this and other items will be fixed in the near
future.
While the message going out does look correct, the current Cheogram
takes issue with it, sending us back the following error:
<message to="cheogram.com" type="error" from="<from>">
<body>Instead of sending messages to cheogram.com directly,
you can SMS your contacts by sending messages to
+1<phone-number>@cheogram.com Jabber IDs. Or, for support,
come talk to us in xmpp:discuss@conference.soprani.ca?join</body>
...
So this code might not be complete, but we won't know for sure until
we're able to do a bit more Cheogram testing. But it could be ready!
Also, we only currently handle group texts with 2 recipients - any
additional recipients will be dropped. It should be trivial to add
more recipients by looping as needed.
Denver Gingerich
created
2f3091f
first successful message, after some more V2 fixes
Click to expand commit body
Now we get a normal message via XMPP on a V2-style JSON blob, after
fixing the type info. Group texts are not yet handled - that will be
next.
Denver Gingerich
created
d2e2d92
translate more parameters to V2 for more progress
Click to expand commit body
Now we get even further than in 6abd653 - since we have updated the
'to' so we use 'owner' instead, which is a string instead of a list.
In particular, we now get a message delivered (woo!), though it's of
the form:
'unknown type () with text: <text>'
So still a bit of work to do yet. Also, we updated a couple other
fields with their appropriate analogs.
Denver Gingerich
created
6abd653
first almost-working acceptance of V2 JSON message
Click to expand commit body
Thanks to 4607bb5 we now had params moved out of the way (since we
can't re-assign to this special variable) so we could now just simply
assign the JSON block to the new params variable (jparams). Since the
Bandwidth V2 API differs a bit from the V1 API (on which this file is
based), we had to comment out some parameters for now, and change
'messageId' to 'id', but other than that the parameters at least
exist in V2.
However, this still doesn't cause the message to flow completely
through the SGX, since we haven't fixed the 'to' parameter, which is
now an array in V2, and so we now get something like:
'jid_key (catapult_jid-["+14165551212"]) DNE; BW API misconfigured?'
But this is way better than crashing the SGX, which is what we got
when passing in V2 messages before this fix.
So we're well on the road to getting V2 messages all the way through
the SGX and probably just need a couple minor fixes now. Yay!
Denver Gingerich
created
4607bb5
variable rename for next commit; no functional chg
Denver Gingerich
created
75d0c17
translator now sends Bandwidth's JSON: w/o tstamps
Click to expand commit body
We previously sent the JSON blob that included the translator- and
acceptor-generated timestamps. However, it is better is the SGX just
receives precisely the JSON that Bandwidth would have sent it, as that
makes it more easily compatible (i.e. if you want to use the SGX
without the acceptor and translator in front of it). So we do that
here, being careful to pass on valid JSON (otherwise Goliath will have
an HTTP 400 fit).
Denver Gingerich
created
7adf7d6
safety: SGX listen address now hardcoded localhost
Click to expand commit body
Since it is easier to manage an HTTP connection between SGX and
translator, and this is likely how it will be used going forward,
remove the default of listening on all interfaces and instead just
listen on the loopback interface. Managing HTTPS is beyond the scope
of the work here, and that would be required in order to safely listen
on other interfaces (and if you know it's safe for your situation, you
can of course just change the hardcoded value back to '0.0.0.0').
Denver Gingerich
created
ba56749
send JSON data to SGX, but SGX can't handle it yet
Denver Gingerich
created
2489f06
add timestamps to message in translator, fix names
Denver Gingerich
created
551336f
update log string, add todo, remove 'json' require
Click to expand commit body
Updated a log message to remove TODO as we won't be putting the ID of
the message in the log, for privacy reasons. This also means that we
won't have any need to read JSON anymore, so we can delete that
"require 'json'" line as well.
Added a TODO about handling another return value (of INCR). This
probably isn't a big deal either way, as an INCR returning an error
multiple times will result in duplicate archived_message keys that
will be caught elsewhere, but there is still a small chance it won't
be caught, so it would be good to fix eventually.
Denver Gingerich
created
ac9a8eb
exists?, update TODO, add warnings, manage pending
Click to expand commit body
We've taken care of a number of TODO items in this commit, including
checking if the archived_message key exists before setting it, adding
warnings about how this program should be treated as a singleton until
some extra atomicity is added, adding a couple TODO items, and finally
have the pending queue being managed correctly (checked at launch time
to confirm emptiness, then popped and checked again after processing a
message).
With this change, all of the queue state is now managed correctly, so
the translator can be run without needing to manually futz with the
queues between each invocation to get them in the right state.
However, there is still more work to do, as the translator does not
yet communicate correctly with the SGX (due to some of the remaining
TODO items, specifically related to how the HTTP request is sent).
Denver Gingerich
created
b949278
fix day total increment, add archived_message save
Click to expand commit body
Fix incrementing of the daily message total so that it doesn't use the
EMPromise-style code imported in 07bcf9c - this code works elsewhere,
but we're not using EMPromise in this file so use the more sequential
method of coding (that works here) instead.
Also add the saving of the passed-on messages to the archived_message
keys. This is done with the 3-day (259,200 seconds) expiration per
the just-removed comment.
The code as of this commit has been tested now, so it does actually
run - the previously version (in 07bcf9c) did not run due to the
aforementioned EMPromise issue.
Denver Gingerich
created
5c5cec2
XEP-0033 supported now so nix old group text code
Click to expand commit body
Now that group texting is supported via XEP-0033 (per a91a575) we are
removing the old way of doing group texting, which effectively reverts
6de670f and then 96856c7. We won't be supporting both ways of group
texting going forward, so delete this to avoid future confusion.
Denver Gingerich
created
a91a575
XEP-0033 now actually supported, offers group text
Click to expand commit body
Now the XEP-0033 support indicated in 8e8fa1b is actually present, and
allows the SGX to receive group texts in this manner per the details
in https://wiki.soprani.ca/SGX/GroupMMS - the other method added in
96856c7 remains as of this commit, but will be removed shortly.
Note that the method parameter for validate_num had to change slightly
here, but the single-number validation code needed no changes at all.
Denver Gingerich
created
8e8fa1b
indicate XEP-0033 support, add several TODO items
Click to expand commit body
The XEP-0033 support is per https://wiki.soprani.ca/SGX/GroupMMS - we
don't actually support it yet, but we will with subsequent commits.
Just turn it on for now to confirm Cheogram sees it.
Denver Gingerich
created
4818f1c
fix queue names (missed in ec34edf) & add key name
Denver Gingerich
created
07bcf9c
add initial timestamping and archived message code
Denver Gingerich
created
ec34edf
fix translator so it uses new queue naming scheme
Denver Gingerich
created
d5c9677
read queue name from file and note needed settings
Denver Gingerich
created
3722226
add TAI times to the list of acceptor's timestamps
Denver Gingerich
created
376ad37
acceptor gives error codes on problems now; tested
Denver Gingerich
created
6b8c0c6
add acceptor and translator, for incoming messages
Click to expand commit body
The acceptor (h2r-bwmsgsv2.php) will receive the messages from
Bandwidth via HTTP and put them in a Redis queue. Then the translator
(r2s-bwmsgsv2.rb) will pick them up from the Redis queue and direct
them to the SGX (sgx-bwmsgsv2.rb), removing them from the pending
queue if the hand-off was successful.
The above components were added in order to improve resiliency of the
system, especially in situations where the SGX may become unavailable
for long periods of time. Bandwidth will send the message again if it
is not received the first time, but it no longer stores the messages
itself in V2, so the consequences of missing an HTTP request are more
severe than in V1.
Denver Gingerich
created
6de670f
enforce sorted ordering in JIDs for group messages
Denver Gingerich
created
96856c7
rudimentary group texting works with numbers array
Denver Gingerich
created
4ede867
a couple non-functional edits: add TODO, rm comma
Denver Gingerich
created
964519e
basic message sending works with these minor fixes
Denver Gingerich
created
a9237ee
first actual implementation: V2 register now works
Denver Gingerich
created
60832f5
rip out Jingle support: can't test & broken anyway
Denver Gingerich
created
3f1ec4a
rename all sgx-catapult, etc., to reflect new name
Denver Gingerich
created
b1aabae
remove sgx-catapult component and rename main file
Denver Gingerich
created
7ccabe8
update README to reflect new intended use of fork
Denver Gingerich
created
537f26b
remove eventmachine pin: haven't needed in a while
Denver Gingerich
created
04a06fe
merge in "Return node in reply to disco#info query"
Click to expand commit body
Analogous to fix for https://github.com/singpolyma/cheogram/issues/71 .
See merge request ossguy/sgx-catapult!18 for the discussion and details behind the merge.
https://xmpp.org/extensions/xep-0030.html#info-nodes requires that *if*
the query includes an optional node, it should be included in the
response.
Stephen Paul Weber
created
ebfd3a0
send MMS on OOB (i.e. via HTTP Upload) - fixes #16
Click to expand commit body
Added a feature that allows the user to send a real MMS (e.g. picture
message) when using their server's HTTP Upload (XEP-0363). With some
clients, like Conversations, the resulting file is sent via OOB, so we
use the presence of a URL in the OOB section to indicate a file is to
be sent. Other ways of describing the URL are for now unsupported, as
we want to ensure that we only do this when the user implies that they
want to send a file.
For a number of reasons, this feature is gated on a per-user flag,
which is off by default. The user may be used to the old behaviour
and not want a real MMS sent, or they may be confused if this feature
breaks when it didn't before (i.e. the carrier supports larger files
when sent via "internal" URL, as is done with Jingle File Transfer,
than it does when sent via "external" URL, as is done here). A new
option will be added to jmp-acct_bot shortly to let the user set this
flag.
Denver Gingerich
created
31c2cb7
record total SMS/MMS sent by each num in TAI days
Denver Gingerich
created
b5902e0
better error on jmp-fwdcall's new "anonymous" JIDs
Click to expand commit body
When the user tries to send a message to an "anonymous" JID (the type
of JID that jmp-fwdcalls will create when it gets a blocked caller ID,
as of https://gitlab.com/ossguy/jmp-fwdcalls/commit/e2032c8 anyway)
provide a more appropriate error message, as the JID does exist, it's
just that the user who left the voicemail isn't available at that JID.
f74eaef
URL-encode JID in media URL; some clients s/\\/\//
Denver Gingerich
created
0eb7d28
merge in "Put <error/> child first on error" fixes
Click to expand commit body
Some clients expect <error/> first and we should always set the type
to :error regardless.
See merge request !17 for the discussion and details behind the merge.
Every error is of type error, and put the <error/> child first for
broken parsers that only get the first child.
Stephen Paul Weber
created
26e6047
merge in "policy-violation" error on empty message
Click to expand commit body
This probably doesn't appear much in the wild, but good to have in
case we do see it.
See merge request !16 for the discussion and details behind the merge.
87c554b
+ "Allow inserting Blather handler before others"
Click to expand commit body
Works well in my tests and, from my understanding, will be helpful in
fixing https://gitlab.com/ossguy/jmp-fwdcalls/issues/7 .
See merge request !15 for the discussion and details behind the merge.