Viktigt för er som använder adresslistor och Active Directory!
Ett flertal flöden i interaktion med TDialog kräver en användare på ena sidan av kommunikationen som är anonym, medan den andra är starkt autentiserad och kommunikationen är skyddad. Ett sådant flöde är visselblåsarfunktion. TDialog lämpar sig för en sådan då informationen är väl skyddad när den kommer in i lösningen och endast lämnas ut till starkt autentiserad och vederbörligen behörighetstilldelad mottagare.
Ett annat flöde är utlämnande av myndighetshandlingar. Enligt lag ska en sådan begäran kunna utföras anonymt, samtidigt som själva flödet ska vara kontrollerat och säkert. Även här handlar det om ett skyddat flöde med anonym ena part, men här tillkommer den extra funktionen att den som skickat begäran också måste kunna ta del av själva handlingen.
I 3.9 finns nu möjlighet att skapa ett eget webbformulär (finns exempelformulär att titta på) som skapar och skickar ett TDialog-meddelande till en förutbestämd uppsättning mottagare. Om så önskas kan den anonyme få ett lösenord efter att ha skickat ett meddelande, vilket möjliggör för den anonyme att ta emot svar och faktiskt ha hela konversationer. Identifieringen är ju endast enfaktor (lösenord) men i gengäld kan personen hållas helt anonym.
Det är sedan tidigare möjligt att skapa länkar som efter inloggning skickar användare till att påbörja ett TDialog-meddelande (används framför allt av Outlook-pluginen). Från och med 3.9 går det även att göra dessa länkar som externa användare.
På så sätt kan en organisation på sin externa webbplats ha en ”Skicka ett säkert meddelande till Socialtjänsten” eller liknande där länken gör att användaren får en BankID-inloggning och efter bankid-inloggning fylls ett meddelande på med lämpligt ämne och mottagare och användaren kan sedan bara fylla på med text och skicka iväg.
OBS! Om användaren måste självregistrera kommer mottagaren och ämnet inte “komma med” i denna release. Vi upptäckte det sent och kommer lägga till det i 3.10. Så, för 3.9 krävs att användaren redan är registrerad för att den externa länken ska fungera.
Ytterligare uppsäkring av ombud. Vi har sedan tidigare gjort det medvetna valet att administratörer inte ska kunna se andra användares meddelandeinformation, och informationen är krypterad på servern. För en angripare med tillgång till databasen på en körande TDialog fanns dock möjligheten att manipulera databastabellen där ombud lagras för att göra sig själv till ombud den vägen. Risken är låg med tanke på att det krävs tillgång till en databas med en körande TDialog, men för att ytterligare öka säkerheten innehåller ombudstabellen numera krypterade hashsummor i anslutning till varje rad, vilket gör att de inte kan ändras.
Klickbara länkar i meddelanden. I 3.9 kommer ni upptäcka att när man skickar ett meddelande med länkar kommer dessa att vara klickbara. Det går att slå av men vi tror det är en önskad funktion så den är på per default.
ConversationId i REST-gränssnittet. Sedan 3.8 sparas vilken konversation ett meddelande tillhör (ursprungsmeddelandet, alla svar på detta och all vidarebefordran tillhör samma konversation). Vi tänker oss framöver att kunna komplettera den vanliga inkorgsvyn med en “konversationsvy”, men i nuläget finns conversationId bara tillgänglig via REST webbgränssnittet. Det gör också att om man använder vårt REST javaexempel behöver man ladda ner det senaste om man uppgraderar servern till 3.9 (vi tror oss dock ha dialog med alla som arbetar med REST-webservices mot TDialog).
I nästa release tar vi till slut tag i e-postintegration. Det innebär att förutom REST kommer det finnas möjlighet att trigga en meddelandeskickning i TDialog genom att skicka ett signerat och krypterat e-postmeddelande till TDialog, och TDialog kommer ha möjlighet att skicka sådana meddelanden.
Tanken är integration med system som skickar och tar emot e-postmeddelanden. Det handlar alltså inte om att skicka känslig information till någons e-postlåda. System vi tänker oss är dels olika verksamhets- och ärendehanteringssystem och dels har vi en plan på att tillsammans med en partner kunna erbjuda ”virtuellt” mottagande av faxmeddelanden där faxmeddelandet blir ett säkert meddelande i TDialog.
Nu börjar REST-API:et användas på allvar, och vi kan dels konstatera att det i grunden är hållbart för det man vill göra, och även att vi fått en massa bra feedback från er kunder om saker som kan förbättras. Det handlar om felkoder, det handlar om genvägar och helt enkelt att göra det ännu enklare att integrera. Dessutom ska vi se till att det går att skicka SDK-meddelanden, Mina meddelanden-meddelanden, Engångsmeddelanden och kanske även Whistleblower-meddelanden via REST-API:et.
När vi kan skicka SDK-meddelanden via REST-API:et har vi fullt stöd för att agera separat meddelandetjänst i SDK, dvs andra klienter kan ansluta till oss med vårt API för att skicka SDK-meddelanden.
Vi tänker oss nästa release före sommaren.
