'xml-not-well-formed' error message

Openfire Openfire Support
1

Hi everybody,

Since severals years we used for a relly old system impossible to upgrade), the XIFF flash CS2 library.

Until Openfire 4.6.7 version all works perfectly, but after upgrade on 4.7.0, openfire server closed connection with this error message.

<stream:error xmlns:stream="http://etherx.jabber.org/streams"><not-well-formed xmlns="urn:ietf:params:xml:ns:xmpp-streams"/></stream:error>

We don"t see in the opefire chanlog what thing can cause this issue.

Here is the code send to the server.

<?xml version='1.0'?>
<stream:stream to='172.30.2.1' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>

<?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="172.30.2.1" id="4mz2u88nsw" xml:lang="en" version="1.0">
<stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>SCRAM-SHA-1</mechanism><mechanism>NTLM</mechanism><mechanism>CRAM-MD5</mechanism><mechanism>DIGEST-MD5</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><ver xmlns="urn:xmpp:features:rosterver"/><auth xmlns="http://jabber.org/features/iq-auth"/><register xmlns="http://jabber.org/features/iq-register"/><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="https://www.igniterealtime.org/projects/openfire/" ver="C63t3QXjdd6n2YpdgZBXO6Y0L4M="/></stream:features>

<?xml version="1.0"?>
<flash:stream to="172.30.2.1" xmlns="jabber:client" xmlns:flash="http://www.jabber.com/streams/flash" version="1.0">.

<?xml version='1.0' encoding='UTF-8'?>
<flash:stream xmlns:flash="http://www.jabber.com/streams/flash" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="172.30.2.1" id="1sdrmx9wm7" xml:lang="en" version="1.0">.
<stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>SCRAM-SHA-1</mechanism><mechanism>NTLM</mechanism><mechanism>CRAM-MD5</mechanism><mechanism>DIGEST-MD5</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><ver xmlns="urn:xmpp:features:rosterver"/><auth xmlns="http://jabber.org/features/iq-auth"/><register xmlns="http://jabber.org/features/iq-register"/><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="https://www.igniterealtime.org/projects/openfire/" ver="C63t3QXjdd6n2YpdgZBXO6Y0L4M="/></stream:features>.

I don"t relly know how to debug this kind of issue :sob:

Any help is welcome, thanks in advance.

2

Iā€™m afraid that the answer is simple, but the solution might not be. In Openfire 4.7.0, support for Flash was dropped: issue OF-2129

3

:sob: ho nooooo !

I understand reason, but I donā€™t really agree with arguments.
Iā€™m sure there are still thousands of people out there using old flash technology.

Itā€™s regrettable.

4

Although Iā€™m not considering to have support for Flash to be reinstated in Openfire, I am curious to its current-day usage. As far as I know, Flash has been dead and buried for a long time now. How is it still used, and how do you work with the rather obvious security implications that using Flash post EOL has?

5

I understand all these security problems, but we use flash internally only to develop a graphical interface that is used for our software, we must also think of the impressive number of internal software that was developed under flash and whose unilateral decision to remove support and availablity by adobe and microsoft signed the death warrant of these software.

Problem is the same with java support, there are thousands of EOL devices in the world that need java support in browsers to be configured and today itā€™s up to everyone to find the right tricks to do it.

This is going to be a real design problem for us and our customers.

Maybe it will be possible, one day, to develop a special plugin like Non-SASL support

Thank you for this answer which saved me long hours of research. this information does not appear in the changelog :+1:

6

I would not object to bringing back support through a plugin, similar to the non-SASL auth plugin. Thatā€™s not a bad idea.

We occasionally miss things in the changelog, but this one was in there: it is the fourth item from the bottom under 4.7.0ā€™s Improvements section.

7

I would not object to bringing back support through a plugin, similar to the non-SASL auth plugin. Thatā€™s not a bad idea

that would be more than fantastic :grin: you welcome

We occasionally miss things in the changelog, but this one was in there: it is the fourth item from the bottom under 4.7.0ā€™s Improvements section.

OMG Iā€™m so sorry I was focus on the notwellformed error message.

8

I would not object to bringing back support through a plugin, similar to the non-SASL auth plugin. Thatā€™s not a bad idea.

Is this kind of modification possible for non expert user ?

9

Itā€™s hard to quantify ā€œexpertā€. A decent background in Openfire development certainly will help.

10

Hi Guss,

I donā€™t want to minimize ours devellopers background, but I think we donā€™t have ressources to do it in internal :pensive:

Do you think possible to ask Openfire devteam to add this feature in a futur version ? More like a future plugin

11

For something like this, you might want to engage professional services.

2 Likes
12

I personally will not prioritize creating such a plugin in my free time, to be honest, as I think that there are many, many other changes that could be applied to Openfire that would benefit a lot more people, while this would mostly benefit a very select audience - one that I expect to consist of commercial entities at that. Speedyā€™s suggestion, to find paid professionals to do this work (I am on that list), seems appropriate.

13

Hi Guus,

OK I understand, any suggestion for the best target to do this job ?

Best regards

14

Given that Iā€™m on that list, I am opinionated. :slight_smile:

What constitutes as ā€˜the bestā€™ might depend on different aspects, like budget, allowable throughput time, quality and support, etc. Most partners on that list offer different combinations of these, which all might be best suitable to you, depending on your own preferences.

15

Thx, I think you can close topic.