Research and Development 1/^Archief/2009-2010/14/Aanvankelijke problemen in fase 1: week 2

• Property "Auteur1" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/14Gebruiker:Sjors Gielen" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur2" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/14Gebruiker:Rob ten Berge" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur3" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/14Gebruiker:Hans Harmannij" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur4" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/14" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Type" (as page type) with input value "{{{type}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Na de aanvankelijke problemen in fase 1, hebben Rob en Sjors hun focus verlegd. In plaats van het constant doorkijken en zoeken naar documentatie om uit te leggen wat ze horen te doen, zijn we broncode gaan lezen en gebaseerd daarop opnieuw servers gaan uitdagen. Daaruit bleek een hoop. We kunnen via speciale update-wavelet-commando's toch servers bereiken. Van daaraf gingen we verder proberen. Deze pagina illustreert de problemen die we daarna tegenkwamen.

De Wave Sandbox

We hebben, net als vorige week, gemerkt dat de Wave Sandbox zich niet aan veel standaarden houdt. Zo zegt XMPP Core dat XMPP-servers specifiek een version-attribuut met hun <stream>-tags moeten meesturen; de waarde daarvan moet minstens 1.0 zijn. Daarbij moet een XMPP-server, als hij version minstens 1.0 meestuurt, ook een features-tag meesturen. De Wave Sandbox doet dit allebei niet, wat de library die wij gebruiken erg in de war brengt: die begint pas met het sturen van commando's bij het ontvangen van zo'n features-tag, en die komt nu niet.

Onze oplossing is op het moment om, zodra we een stream-tag zonder version tegenkomen, ervanuit te gaan dat die features-tag niet meer komt, en al meteen door te gaan met het aanvragen of sturen van data.

We hebben dit geprobeerd, en kregen een foutmelding van de server - "not authorised":

SENT <?xml version='1.0'?><stream:stream to='wavesandbox.com' xmlns='jabber:server' xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
RECV <stream:stream id="00D1BB864E69F8A1" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:server" xmlns:db="jabber:server:dialback">
SENT <message type='normal'  from='wave.dazjorz.com'  id='1337-1' to='wave.wavesandbox.com'>
  <request xmlns='urn:xmpp:receipts'/>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items>
      <item>
        <wavelet-update          xmlns='http://waveprotocol.org/protocol/0.2/waveserver'          wavelet-name='dazjorz.com/dazjorz.com!WAVEID1/WAVELETID1'>
          <applied-delta><![CDATA[CiT...MwE] ]></applied-delta>
        </wavelet-update>
      </item>
    </items>
  </event>
</message>
RECV <stream:error><not-authorized xmlns="urn:ietf:params:xml:ns:xmpp-streams"/></stream:error></stream:stream>
RECV </stream:stream>
WARNING Socket error: The remote host closed the connection

Dit is in principe goed nieuws; we hebben een bericht gestuurd aan de server en die antwoordt dat we "niet geautoriseerd" zijn. Die server sluit daarna de verbinding, omdat dat moet bij een <stream:error>. We gaan verder proberen om te kijken of we een wat positiever antwoord van deze, of andere servers kunnen krijgen.

Geen antwoord krijgen

We zijn erachter gekomen dat verschillende servers géén antwoord sturen als de 'to'-attribuut niet perfect klopt - bijvoorbeeld, als we aan de server wave24z.com een 'to'-attribuut meesturen die niet exact gelijk is aan "wave24z.com", dan krijgen we nooit antwoord, ook geen foutmelding. Daarnaast geven servers tot nu toe altijd een "invalid-from"-error, die aangeeft dat de from="" die wij meesturen incorrect is. Daarover gaat het volgende kopje.

"Invalid From"

Wederom konden we door slechte documentatie nergens vinden waar die foutmelding door komt. Herhaaldelijk proberen wees ook niets uit. Het doorkijken van daadwerkelijke broncode van een XMPP-server bevestigt dat de fout komt doordat het domein van onze server nog niet goedgekeurd is. Echter de reden daarvoor was anders dan wij vermoedden.

Het hele idee van een TLS-certificaat is, volgens ons, controle op een domeinnaam. Als een certificaat geverifieerd is, moet de domeinnaam in dat certificaat ook vertrouwd zijn. Dit blijkt echter niet het geval te zijn. Een XMPP-server, of althans de specifieke server die wij bekeken (en die ook gebruikt wordt voor Google Wave, vaak), vereist een extra controle van een hostname via SASL of Dialback. SASL valt direct af, want er zijn geen methoden die twee losstaande servers kunnen gebruiken[0]. Dan blijft alleen Dialback nog over, en dus moeten wij dat gaan implementeren.

[0] SASL is vooral handig als twee peers elkaar al kennen, zoals een client die met wachtwoord inlogt op een server, of twee servers binnen hetzelfde bedrijf.

Dialback

We hebben vervolgens op een botte manier dialback geïmplementeerd, door simpelweg een server op te zetten die alle dialback-requests goedkeurt. Het bleek echter, dat de andere server na het slagen van de dialback opnieuw een verbinding begon met die simpele server. Die server was alleen in staat om dialback-requests goed te keuren, en kon dus geen andere streams behandelen, waardoor het faalde. Na wederom de documentatie doorgelezen te hebben, bleek dat het voor servers verplicht is twee onafhankelijke TCP verbindingen met elkaar te hebben, één voor te sturen berichten (waarbij de andere server foutmeldingen op stuurt), en één voor de berichten die vanuit de andere server verstuurd worden (waarop wij dan foutmeldingen terug mogen sturen).

We zijn dus begonnen met het implementeren van dialback in QXmpp en de uiteindelijke Wave-server waar we mee bezig waren. We liepen hier opnieuw tegen veel problemen aan. Het lijkt erop dat een andere Wave-server alleen de dialback-request stuurt als de XMPP-stream op een specifieke manier opgezet wordt. Wij moeten dus detecteren dat een XMPP-server de verbinding alleen maar opende voor een dialback-request. Dat is echter helaas nog niet gelukt, want bij elke poging die wij doen om zo'n dialback-request-streamstart te detecteren, is er wel een server die zijn stream anders start. We zijn nog bezig met proberen of we daar een goede oplossing voor kunnen, zo, dat we bij elke server dialback goed kunnen laten aflopen.