Microsoft Teams loads but renders a blank (white) window

Today I've spent like an hour trying to fix a sudden issue - Teams loads, the loading window shows correctly but then, instead of a normal main window, all I got was a blank white window.

It never happened before and of course I've tried to search for similar problems people had and possibly found solutions. I've tried all of this:

• closing/reopening Teams
• shutting down the machine
• reinstalling Teams
• removing both ..\App Data\Local\Microsoft\Teams and ..\App Data\Roaming\Microsoft\Teams
• creating a custom link that points to Teams.exe instead of Update.exe --processStart "Teams.exe" where the default link points to
• forcing a custom power scheme for the application so that for my dual GPU machine, the correct GPU is used

None of these worked.

What I suspected is that the Teams problem is somehow related to account switching. The default Windows client doesn't support multiple accounts, having two of them (for my two organizations) means I have to sign out and relogin to the other account every time I want to use it (alternatively I could switch to another user profile). This always worked. But today - the white window was clearly related to signing out of a working session and trying to sign into the other account.

What people recommend is to remove all Windows 10 linked accounts (work/school accounts in the Windows Credentials Manager) and this didn't help either. Somehow I noticed, however, that even removing a user profile (..\App Data\Roaming\Microsoft\Teams) caused my Teams to show the login prompt but skipping the password prompt. This leads to an interesting question: where does Teams cache user credentials? Interestingly enough, people also noticed this (Google "Teams Not Asking for Password").

The end of this story is: while I was not able to find a way to clear the cache locally, I just changed my domain's account password in the remote organization's registry and then cleared the Teams profile. This once again triggered the login prompt but this time it also asked for a password. And Teams loaded correctly.

Hope this helps someone in trouble.

C# Puzzle No.24 (intermediate)

Given a generic interface definition

public interface IDoSomething : IDisposable { }

please explain why this is possible

class DoesSomething<String> : IDoSomething<String>
{
    public void Dispose()
    {
    }
}

and this is not possible (doesn't compile)

class DoesSomething<string> : IDoSomething<string>
{
    public void Dispose()
    {
    }
}

An explanation can be found here.

Węzeł krajowy dla .NET - zakończenie zasadniczych prac części klienckiej i serwerowej

Moja implementacja biblioteki integracyjnej dla .NET do Węzła Krajowego, OldMusicBox.EIH.Client, o której wspominałem w poprzednich wpisach otrzymała właśnie sporą aktualizację dodającą do już wcześniej istniejącej demonstracji części klienckiej (czyli przykładowej aplikacji która pokazuje jak implementować klienta węzła krajowego), implementację części serwerowej.

Zwracam uwagę na ten element - istnieje demonstracyjnej wersji serwera oznacza bowiem, że prace integracyjne we własnej aplikacji można rozpocząć od prób integracji z tą przykładową implementacją serwera. Mój serwer, podobnie jak Symulator Węzła Krajowego, nie wymaga posiadania kont, nie wymaga w szczególności wpisywania haseł - użytkownik sam wybiera jakimi atrybutami chce się zalogować. Następnie symuluje część serwerową protokołu SAML2 w takiej wersji w jakiej implementuje go Węzeł Krajowy, zachowując dialekt SAML2 (Artifact Binding) oraz sposób szyfrowania asercji.

Jest to szczególnie użytecznie w sytuacji, w której implementacja klienta nie ma związku z załączoną tu częścią kliencką - na przykład wtedy kiedy klient powstaje w Javie, node.js czy PHP. Dla takich aplikacji klienckich pierwszą możliwością przeprowadzenia testu integracyjnego był do tej pory Symulator Węzła Krajowego. Teraz natomiast można użyć załączonej aplikacji i zasymulować część serwerową mając ją pod całkowitą kontrolą - w szczególności można ją w pełni debugować i dzięki temu prześledzić w którym miejscu aplikacja kliencka popełnia błąd.

Dla zainteresowanych - to było całkiem nietrywialne. Implementacja części klienckiej była wzorowana na przykładowym Javowym kodzie części klienckiej, jaka jest dołączana do dokumentacji WK. Ale symulowanie serwera wymagało zrozumienia algorytmu Key Agreement w wersji dla krzywych eliptycznych a potem całego mnóstwa prób i błędów. Istniejąca implementacja wymaga od klienta posiadania klucza prywatnego (bo klucz publiczny serwera jest częścią informacji zwracanej w zaszyfrowanej asercji), a serwer potrzebuje, oprócz swojego certyfikatu i klucza prywatnego, również klucza publicznego klienta.

Węzeł Krajowy w .NET/C# na github

Na github powstało repozytorium, w którym znajdzie się implementacja klienta .NET dla Węzła Krajowego, OldMusicBox.EIH.Client (EIH jest tu skrótem od Electronic Identification Hub, ten termin wygląda na zamiennie używany z Electronic Identification Node).

Węzeł Krajowy w .NET - kamień milowy

Od ostatniego posta na temat Węzła Krajowego minęło sporo czasu, niestety, było tysiąc i jeden rzeczy do zrobienia i temat musiał czekać na swoją kolej.

Udało się wygospodarować trochę czasu w piątek 11.12 i dziś i z przyjemnością puszczam w eter wiadomość, że kod działa od początku do końca i odzyskuje dane logowania użytkownika w .NET. Pozostaje całość posprzątać, zrefaktoryzować i pozostawić tu i ówdzie furtki na zachowania nieprzewidziane - na tę chwilę działa to tylko z witryną symulatora.

Po raz kolejny wypada pozazdrościć Koleżeństwu programującemu w Javie, ponieważ tam wygląda to na dużo prostsze, w szczególności w ostatnim kroku dekodowania zaszyfrowanej asercji można się wzorować na załączonym przykładowym kodzie w Javie. Niestety, programując w .NET trzeba umieć całość przenieść na odpowiadające elementy biblioteki standardowej i Bouncy Castle. I to niestety, nie jest najłatwiejsze.

Stosowny kod zostanie w niedługim czasie opublikowany na github.

Materiały edukacyjne - funkcje w Javascript

Czwarty wykład z Wybranych elementów praktyki projektowania oprogramowania, o programowaniu funkcyjnym w Javascript, to jeden z moich ulubionych, łącznie z kolejnym o obiektowości prototypowej. Tu opowiadam o tym jak w Javascript zobaczyć język funkcyjny, z takimi elementami funkcyjnymi jak funkcje wyższych rzędów, rekursja, domknięcia, kontynuacje. Zrozumienie tych elementów języka znacznie ułatwia swobodne poruszanie się w bibliotekach UI, takich jak React (komponenty funkcyjne).

Zapraszam do oglądania.

Węzeł Krajowy w .NET - rozpoczęcie pracy

Rozpocząłem prace zmierzające do wsparcia Węzła Krajowego w bibliotece klienckiej SAML2/ePUAP. Podstawą pracy jest dokument Instrukcja integratora DU opublikowany przez COI.

Po rozwiązaniu problemów z SAML2 przy integracji z ePUAP, integracja z WK wnosi kolejny poziom wyzwania. W szczególności:

Węzeł Krajowy wymusza kryptografię opartą na certyfikatach eliptycznych (ECDSA). Problem jest taki że o ile biblioteka standardowa .NET obsługuje szyfrowanie/deszyfrowanie na takich certyfikatach, SignedXml już nie - w metodzie ComputeSignature można wprost podejrzeć if-a, który sprawdza typ certyfikatu i jeśli to nie jest RSA, wyrzuca wyjątek. Jest to poważne zaniedbanie!, z którym niełatwo sobie poradzić (kto ma ochotę na napisanie samodzielnie implementacji podpisywania XMLi, która obsługuje wszystkie niuanse, transformaty, itd. i przy okazji dodaje obsługę certyfikatów eliptycznych?)

Węzeł Krajowy upraszcza komunikację bo nie wymaga dodatkowego kroku z wołaniem usługi, ale za to - asercje o użytkowniku zwraca w postaci zaszyfrowanej. Problem w tym że na tę chwilę nie mam pojęcia jak to chwycić w C#

Na dzień dzisiejszy jest kawałeczek sukcesu, taki pierwszy set z trzech. Mianowicie, potrafię wygenerować sygnaturę tak żeby AuthnRequest był poprawnie obsłużony. Jeśli to komuś pomoże, to używam Bouncy Castle i uwaga - wbrew intuicji nie można używać signera SHA256WITHECDSA tylko SHA-256withPLAIN-ECDSA - straciłem na tym kilka godzin.

W kolejnych dniach dalsza część pojedynku...